On 23 Aug 2001 07:15:59 +0900, Avi Bryant wrote:
> You're suggesting that mix-ins be added below the class they're being
> mixed into, rather than above it.  The main problem I can see with this is
> that it prevents the class from overriding methods in the mixin.

Yep. I was originally going to suggest that modules and classes could be
merged together by using the rule "multiple inheritance but only the
first one is the parent", but it occured to me that a child class has to
be specifically invoked whereas a mixin alters the class itself.

Given that, I thought that classes could be for "above class"
inheritence and mix-ins could be for "below class" inheritence. Since a
class could be parent to multiple mixins, chaining or some other simple
scheme would be needed to avoid that old problem.

Still, chaining up wrappers would be pretty horrible code, much like
deep inheritance trees are pretty horrible too.

> However,
> it might be interesting to figure out a way of allowing subclass-mixins
> as well as superclass-mixins.  It seems like there ought to be a (maybe
> inefficient) way of doing this with singleton classes, at least.

It would be amusing to see how many programming paradigms Ruby can
support without any strange syntax. :)