Re: Virtual classes and 'real' classes -- why?

On Thu, 2007-03-29 at 08:30 +0900, John Lam (CLR) wrote:
> More interestingly though, is where does the new method comes from
> when doing A.new. We believe that once we've looked at all of the
> ancestor classes' eigenclasses for new, that we then hit the Class and
> Module classes in the list of eigenclasses. Does that make sense as
> well? It's a bit strange because you start off looking through the
> eigenclass hierarchy for new, and then switch to the class hierarchy
> at the very end for Class, Module and Object.

I don't see it being particularly strange -- once we exhaust the
applicable eigenclasses, we start looking at the class hierarchy for the
class's _class_ (Class), just as we do for any other object.  The only
difference is that for class objects we consider more than just the
object's own eigenclass, including also the class's ancestors (not the
class's class's ancestors).

> Is this how things are actually implemented? (BTW I'm not lazy here -
> we cannot look for ourselves).

More or less.

> Also, as long as we respect this lookup mechanism, does anyone forsee
> any problems in merging the identities of the eigenclass and class
> objects into the same object (other folks who have code that
> explicitly depends on the behavior of the eigenclass hack -- not sure
> what this really means at this time though).

The class << self ; self ; end idiom is somewhat heavily employed in
Ruby metaprogramming, so I'd recommend against breaking it.

However, it doesn't really matter how you implement things, so long as
class << obj always gets you a context where self is an object which
behaves like the "virtual class" of obj.  There's no reason it couldn't
be e.g. some sort of lazily created proxy object rather than an actual
virtual class.  But I think always having explicit virtual classes will
give you a cleaner implementation.

Note that virtual classes also have their own virtual classes (ad
infinitum...); this works because Ruby creates virtual classes lazily,
deferring creation until the first singleton method is added to an
object.

-mental