From: transfire@...
Date: 2006-06-13T11:38:42+09:00
Subject: Re: Why the lack of mixing-in support for Class methods?


Logan Capaldo wrote:

> I think a little context has been lost in this conversation, if I may
> be permitted to go back and quote Mr. Schierbeck again:
> > I'm wondering why it's not possible to #include a class into a
> > module/class -- making the only difference between classes and
> > modules the ability to instantiate (#allocate). That way, you could
> > do something like this:
> >
>
> I do not see how straight up #include-ing a _class_ would _not_ be
> multiple inheritance.

Techincally it isn't. Multiple inheritance can have iheritance
structures like so:

M   N
 \ /
  C

Single inheritance (like Ruby) is strictly like this:

  N
  |
  M
  |
  C

With Ruby, it doesn't matter how many modules you include, it's still
just a line of single inheritance. What's unique about mixins is that
they allow us to slip "ancesotors" in between a class and it's
superclass, thus augmenting behavior in a way similar to MI, but
wiithout many of the additional complexities of MI.

> I'm was not talking including class methods, I'm talking about writing
>
> class A
> end
>
> class B
> end
>
> class C
> end
>
> class D < A
>    include B
>    include C
> end
>
> IOW, erasing the distinction between classes and modules, which is
> what Mr. Scheirbeck suggested, and what I took exception to.

Fair enough. But let me make clear that MI is not a wholly satisfactory
answer to Mr. Scheirbeck query. The answer is more subtle, a
distinction between module and class help promote two different forms
of behavioral inheritance, one primary (class) and the other secondary
(module). This is actually quite realistic. Think of a Car (class) with
optional feature like FullyLoaded (module). I don't think anyone is
suggesting we remove that disticition, even if it is *technically*
debatable.

What _was_ suggested though, is that the "class-level" of a module
might be more appropriately a "module-level". Classes would still have
class-levels, but by giving modules their "own kind" in this role, the
difficulty of extending a class via a module's "module-level" is easily
solved --a solution which is the hope of this thread. And such a
solution, I reitererate, does not in any way constitute MI.

T.