On May 14, 2009, at 8:25 PM, J=F6rg W Mittag wrote:

> Joshua Ballanco wrote:
>>
>> As it turns out, they can be very
>> handy for implementing instance-specific methods,
>
> Exactly. It is my understanding that they were only added as a place
> to "stick" per-object methods. MRI already had classes, so why not use
> them? If you stick per-object methods in an eigenclass you need
> exactly 0 new constructs in the interpreter, 0 changes to method
> lookup and just one if-condition in superclass lookup. Plus, you can
> also implement mixins the same way. That's a *lot* of leverage for
> essentially one line of code.
>
> AFAIK, the fact that they were exposed to the programmer is more of an
> accident than a well-designed thought-out language feature.

Right. So then the question: is there a compelling reason that they =20
should be allowed to be subclassed? (I mean, other than the obvious: =20
"Because that's not the way Ruby was designed" answer.) I cannot come =20=

up with any compelling technical reason why the artificial limitation =20=

of being unable to subclass "virtual classes"[1] should exist. I also =20=

don't see what, besides this artificial limitation, is keeping Ruby =20
from having, at its heart, a fully prototype based inheritance system.

- Josh

[1] That's what the exception calls them, so I'd throw that into your =20=

pot of valid names in the running.=