> I have no doubt when the Trait designers said they were gonna 
> tackle the 
> Collection heirarchy with traits that they were doing it for 
> just this 
> very reason....

Exactly. The problem is that single inheritance simply isn't expressive
enough to model something like the Collection hierarchy. Every
collection class, can be classified according to different (and often
orthogonal) properties such as sequenceable, extensible, writable, etc.
In addition, you have several properties characterizing their
implementation (e.g., hashed implementation, arrrayed implementation,
linked implementation, etc.). Unfortunately, single inheritance is not
able to combine these properties in very flexible ways. Therefore, you
only have 2 choices: Either duplicating code, or sticking the code very
high up in the hierarchy although some subclasses won't use it.
Sometimes it even happens, that a method is defined in a class A,
disabled in a subclass B, and then again enabled in a subclass C of B.

Well, Andrea and I worked on the refactoring all day today. We are not
quite done, but it *really* looks promising. It seems that Traits
exactly provide the flexibility you need. And the best thing is that
even if a hierarchy is written using many possibly deeply nested Traits,
it does *never* affect the understandability of the code. This is
because the Traits adhere to a "flattening property", which says that
the the place (i.e., the Trait) where the code is defined has no
semantical meaning. Therefore, a class that is built from Traits can
always be viewed *and* edited as if all the methods were implemented in
the class itself, and such a view does never require any changes to the
involved methods. 

This means that if a programmer does not want to know about Traits, he
can work with the class in the *exact* same way as if it were
implemented using single inheritance (and code duplication). In fact,
when one edits a method that is actually implemented in a Trait in a
flattened view of a class that uses this Trait, the edited method simply
gets defined in the class and therefore hides the trait implementation.
But: It does not change the actual traits and therefore the behavior of
the other classes using that Trait. (In order to do that, you have to do
changes to the Trait rather han to the class that uses the Trait).

This means that even a system that is built from thousands of Traits
*never* has any negative impact of code understandability. In fact, it
even improves it because it offers the user many perspectives for
viewing and editing the code: Besides the flattened (i.e., traditional
single inheritance) view, he can look at it in composite views at any
level of details. Then, he sees how the class is actually composed from
the different raits and how these Traits are glued together.

Note that this is an essential difference to both Mixins and MI. There,
the place of a method has semantic meaning and therefore, this
flattening is not possible. We believe, that this is part of the reason
why these approaches are not very well accepted in practical languages. 

Well, enough advertisment. I hope that we make some progress with the
refactorings in the next days. Then, I plan to release a first beta
version of my Traits system sometime in November. At the same time, I'll
also make a paper I am about to write about Traits available as a
Tech-Report.


Nathanael


> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Daniel Joyce
> Sent: Friday, October 25, 2002 1:37 AM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: is Missing multiple inheritance in sqeak a drawback ?
> 
> 
> 
> > Or SortedCollection>>addLast: to ride the horse to death ;-)
> >
> > Stephan
> 
> But that's because inheritance, to maximize code reuse in ST 
> and Java, 
> forces you to inherit unsensible messages for some versions of 
> collections, and so you get all sorts of messages that the 
> object says 
> it understands, but doesn't really ( either it's been DNUd, or 
> something else ).
> 
> The same holds true in Java....
> 
> Traits would allow us to factor out protocols into a seperate 
> heirarchy 
> from the collections... Code reuse w/o non-sensical messages cropping 
> up in the tree. And I think traits can be used for much much cooler 
> things as well.
> 
> I have no doubt when the Trait designers said they were gonna 
> tackle the 
> Collection heirarchy with traits that they were doing it for 
> just this 
> very reason....
> 
> -Daniel
> 
>