On Wed, Dec 9, 2009 at 12:46 AM, Andreas Raab <andreas.raab at gmx.de> wrote:

> Colin Putney wrote:
>
>> Well, going back to the original Traits paper[1]:
>>
>
> Thanks for the quotes.
>
>
>  And later in the same section (note the third rule):
>>
>>    Trait composition respects the following three rules:
>>    • Methods defined in the class take precedence over trait methods.
>>    This allows the glue methods defined    in a class to override methods
>> with the same name provided by the
>>    used traits.
>>    • Flattening property. A non-overridden method in a trait has the
>>    same semantics as if it were implemented    directly in the class using
>> the trait.
>>    • Composition order is irrelevant. All the traits have the same
>>    precedence, and hence conflicting trait    methods must be explicitly
>> disambiguated.
>>
>
> Indeed. It was this talk about "explicit disambiguation" (which I recalled
> from other discussions) which led me to understand that "self traitConflict"
> is to be interpreted as "please be explicit about which of the methods you'd
> like to use" instead of "this method ain't here".
>
>
>  I don't see any references to XOR operations, so that must have come from
>> some other discussion of Traits. (I'm pretty sure I didn't make that up from
>> thin air!) Instead the paper talks about explicit conflicts which have to be
>> resolved, consistent with the #traitConflict methods the Squeak
>> implementation creates.
>> So I guess "does not show up in the composition" is wrong. It would be
>> better to say "creates a conflict that must be explicitly resolved." But
>> still, I think it's fair to say that this is one of the defining features of
>> Traits, in contrast with Mixins, which do follow a "last one wins" method of
>> resolving conflicts.
>>
>
> I suppose. I find it pretty useless but then again, I find MI in general
> pretty useless so there isn't much difference to me :-) (but rest assured
> that I'll leave the behavior alone for those people who care)
>

I was so enthused about the Borning-Ingalls multiple inheritance
implementation that I spent a lot of time in the BrouHaHa variant of
Smalltalk-80 V2 fixing bugs (like making file-outs and class redefinitions
work without regenerating spurious conflict methods), and providing an
extension to the class definition to specify the resolution of conflicts
(*).  But after all that work there were precisely three instances of MI in
the system; I made ReadWriteStream inherit multiply from ReadStream and
WriteStream, DateAndTime inherit multiply from Date and Time and, of course,
Queen inherited multiply from Rook and Bishop (**) :)


(*) P.S.  e.g. you could say
Class named: #ReadWriteStream
    superclasses: 'WriteStream ReadStream '
    inheritanceAnnotation: 'WriteStream overrides: ReadStream'
    instanceVariableNames: ''
    classVariableNames: ''
    category: 'Collections-Streams'!


(**) P.P.S. Queen's MI was entirely spurious.  The only method that Bishop
and Rook defined was isPotentialMoveTo: position in: board.  Since it was
faster to reimplement isPotentialMoveTo:in: directly than as
^(Rook. isPotentialMoveTo: position in: board) or:
[Bishop isPotentialMoveTo: position in: board] it didn't actually inherit
anything from them.



> Cheers,
>  - Andreas
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091209/8fcc4042/attachment.htm