From: Trans <transfire@...>
Date: 2005-07-29T00:56:00+09:00
Subject: Re: What's so special about operators, built-in classes and modules?


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.

> > 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? BTW I think that handling this kind of "MI" would be
fairly straight forward with ancestor directed calls (eg.
AModule\amethod)

2c,

T.