On May 14, 2009, at 8:25 PM, Jöòg 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  
should be allowed to be subclassed? (I mean, other than the obvious:  
"Because that's not the way Ruby was designed" answer.) I cannot come  p with any compelling technical reason why the artificial limitation  f being unable to subclass "virtual classes"[1] should exist. I also  on't see what, besides this artificial limitation, is keeping Ruby  
from having, at its heart, a fully prototype based inheritance system.

- Josh