A possible clever trick for extension writing

[Kevin Bullock]

On Nov 27, 2011, at 10:49 AM, Greg Ward wrote:

> Drawback: the "template" class that implements a lot of essential
> extension logic isn't a real class (it's never instantiated or
> subclassed) -- it's just a namespace created with the convenient
> "class" syntax. The real class is hidden away behind the scenes.

This doesn't seem so different from the current case, in which the "real" class you see in the code is actually a template from which the actual subclass is created at runtime. The only difference I see is that an extra class is created for each extension (the template in addition to the actual repo subclass). The actual subclass is still only accessible as repo.__class__ (which is the same as the current case except inside the current batch of reposetup() methods).

Of course there'd be an easier way to solve this in Ruby:

module SimpleRepo
  def tags
    result = super(simplerepo, self).tags()
    result['first'] = self.lookup(0)
    return result
  end
end
def reposetup(repo)
  repo.extend(SimpleRepo)
end

What that repo.extend does is to insert the module into repo's inheritance hierarchy, just _below_ repo's actual class, so that the module methods get called before the class' methods. This works because every object sprouts an invisible virtual class when necessary, into which modules can be included. Not so different from what you're proposing: the "module" is the template class, and the "virtual" class is the dynamically-generated class.

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock