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.
Locked
