Maybe I'm going to say something trivial or something you have discussed on
the list before or it is on the Traits papers (although I do not remember
that is the  case for the later), but anyway, here it goes.

Something I see is that Traits should be use only to to implement
"orthogonal" behavior to "the main problem". It is common to see Traits as a
way to share "code", it is common to see examples of traits where it looks
that the developer is taking design decisions based on reusing code, but I
think that sharing code is a result of using Traits, it is not the end, not
the objective of Traits.
I came to this idea reading Kent Beck's paper called Time Travel (
http://www.manfred-lange.com/publications/TimeTravel.pdf) were he provides a
pattern to add the time axis to any model. The implementation they show is
too trivial, for example, the History pattern has to be implemented in all
classes of the objects we want to track changes (or versions). Another
solution could have a "History" superclass for all those classes, but we
know this is not a good design decision and it is not practical with single
inheritance.
With Traits, we could have a HistoryTrait and make all the classes we want
to have this behavior to use it. Having versions of an object is a "trait"
of it.
Another example is the Magnitude behavior. There are too many things that
behave like Magnitudes but not all of them are subclasses of the class that
represents this idea. If we think in Magnitude as an "orthogonal" axis, it
make sense to have Magnitude implemented as a Trait.
Of course, the question is: is being a Magnitude or a "History" really
orthogonal to the main problem? or should we considered them to be at the
same "level" of the mail problem?
I do not see the answer very clear with Magnitude, but I do with "History".
I see History to be in a completely different level of abstraction, even
more, with one of my students we are thinking about changing the meta-model
to implement this behavior and therefore all objects could track their
changes. But, is it worth it? could Traits be enough to implement this? may
be yes.
So, like any tool, if you do not use it right you can make disasters. With
Traits is the same, if you just use it just to share code, you will end up
with one Trait per method, but if you use Traits to implement "orthogonal"
behavior, it sounds like a good tool. Of course, the problem is to find this
"orthogonal" behavior and to modeled it right, but hey, that problem exists
with Traits or with out them.
So, if what I'm saying is true, maybe reimplementing the Stream hierarchy or
the Collection hierarchy is not a good idea for Traits... what is the
"orthogonal" behavior we can find in this hierarchies? I do not see one...
all the traits that came from these examples are at the same level of
abstraction of the classes that model the main problem and that is the
reason why they look "tricky"...
Anyway, maybe traits are a good tool to implement behavior that is in the
middle between the meta-model and the model per se... just a thought.

Bye,
Hernan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080210/be996817/attachment.htm