From: Logan Capaldo <logancapaldo@...>
Date: 2006-06-13T07:06:38+09:00
Subject: Re: Why the lack of mixing-in support for Class methods?


On Jun 12, 2006, at 5:43 PM, Alder Green wrote:

> On 6/12/06, transfire@gmail.com <transfire@gmail.com> wrote:
>>
>> Daniel Schierbeck wrote:
>> > Logan Capaldo wrote:
>> > > Then you have multiple inheritance.
>> >
>> > Yes.
>>
>> Not really. Mulitple Inheritance provides orthogonal heirarchies.
>> Ruby's is strictly linear. If what you say were true then Ruby would
>> already be MI since modules can be used to add behavior to both class
>> and instance levels, and readily associated together as well, as  
>> Ara's
>> example clearly demonstrates. To think this consititutes MI and thus
>> making specialized restrictions of code separation to repress it,  
>> only
>> serves to complixify the situation, not the other way around. It's  
>> like
>> trying to prevent someone from getting to their destinatin by not
>> allowing them to turn right --they'll still get there, they'll just
>> turn left three times.
>>
>> T.
>>
>>
>>
>
> Exactly.
>
> 1. Multiple module inclusion is not multiple inheritance. Even if you
> think it is - Ruby already has it. So unless you're arguing for its
> removal - and nobody seems to want that - it's a moot point.
>
> 2. You may debate whether mixing-in class methods is a "bad" practice
> in some sense, and should therefore be discouraged - or at least not
> encouraged by adding elegant, clear and standard language support for
> it.
>
> But:
>
> 2a. It can't be that bad, since nobody is arguing that it should be
> disallowed completely.
>
> 2b. It doesn't seem to be widely considered "bad", at least not by
> several skilled Ruby hackers. Rails is highly regarded codebase, and
> the ClassMethods hack is all over it. Rails is the only codebase I'm
> (vaguely) familiar with, but posts in this thread indicate that other
> good codebases use similar hacks to accomplish the same programming
> strategy.
>
> 2c. Of course, one may argue that even if mixing-in of class methods
> is done by many skilled Ruby hackers, and is a vital programming
> strategy in many high quality Ruby programs, it is still "bad" in some
> theoretical sense. This is a subjective argument that cannot be
> resolved. But one of the major attractions of Ruby for me is the
> TIMTOWDI philosophy. I did not think Ruby would try to discipline its
> coders by inconveniencing them. Not that it would matter much - mixins
> would continue to be used for classs method inclusion.
>
> So in short, since it seems many people are mixin class methods, it
> would be nice if it were handled by a standard - hopefully convenient,
> elegant - language feature.
>
> -- 
> -Alder
>

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.

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.