From: gwtmp01@...
Date: 2006-06-14T04:14:08+09:00
Subject: Re: Why the lack of mixing-in support for Class methods?


On Jun 13, 2006, at 12:50 PM, ara.t.howard@noaa.gov wrote:
>   module M
>     def initialize
>       'ha'
>     end
>   end
>
>   module N
>     def initialize
>       'ha ha'
>     end
>   end
>
>   class C
>     include M
>     include N
>     def initialize
>       'hmmm'
>     end
>   end
>
> with classes, this is __always__ the situation.  obviously it can  
> be dealt
> with - but it's a little less straight forward than the 'normal'  
> mixin effect.

I don't see how your example is any different than the problem  
presented by
nested includes.  The ordering of ancestors and thus the resolution  
of method
lookup is well defined in either case, no?

> not for or against here - but i do believe being able to mixin  
> classes,
> without some really slick handling of super/initialize, state, and  
> class_init
> on ruby's part would be confusing for most.  in otherwords, ruby  
> would need to
> become mi to do so.

Isn't this already an issue with module-only includes?  There was some
discussion on this recently I think.

We got to this point in the discussion because of the desire to auto- 
mixin
module methods, which happen to reside inside a singleton *class*.   
So this
raised the question of what does it mean to include a class? I still  
don't
like the idea of auto-mixin of module methods but to make sense of  
that idea
you must somehow grapple with the notion that instance methods can
be implicitly extracted from a singleton class object (i.e. an  
instance of Class).
Once you go down that road, it just begs the question of why you  
can't do that
with any class object.


Gary Wright