On Fri, 29 Jul 2005, Trans wrote:

>
> Ara.T.Howard wrote:
>> because otherwise including module could clobber class methods which generally
>> include hooks to create instances like 'new', 'instance', 'parse', etc.  if you
>> replace the set of methods responsible for stamping out instances you are not
>> 'mixing-in' functionality to those instances - but changing what type those
>> will be.  there is a fundemental difference here.
>
> That assumes no other way to deal with this "clobbering" is utilized. I
> think your overstating to say there is a fundemental difference. It
> still boils down to the "Duck" --walk, talk and all that.

i'm not sure i agree - so long as ruby has types/classes/whatever returning a
different kind of one sure seems alot different than returning a specialzation
(subclass) of one.  however 'type' is pretty muddy in ruby as we all agree.

>>> No, it would not be possible to retain full backwards compatibility, but I
>>> cannot think of a real-world case in which actual problems would result.
>>
>> added multiple inheritence semantics for module inclusion would not be
>> backwards compatibile imho.
>
> What would break?

i've given some examples in this thread from my own code...  i assume there
would be more.

> BTW I think that handling this kind of "MI" would be fairly straight forward
> with ancestor directed calls (eg.  AModule\amethod)

sure - it could be done.  but only by matz.

cheers.

-a
-- 
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| My religion is very simple.  My religion is kindness.
| --Tenzin Gyatso
===============================================================================