On Fri, 16 May 2008 10:52:57 +0200, Ryan Mitchley wrote:
I am genuinely curious to see a simple example that clearly demonstrates the advantages of traits.
It is my perception (or misperception) that traits are an attempt (perhaps unknowingly) to bring multiple inheritance into the language.
I think you can easily judge for yourself whether or not a system gives you multiple inheritance (MI):
o in Smalltalk every class has at most one superclass o every MI class has at least two superclasses o in Smalltalk a method can send to self or super o a method in an MI class can choose to which super it sends
Compare Squeak's traits to these statements ...
/Klaus
As I see it, this confuses Y Is-A X (i.e. Y subclasses X) with Y Has-A-Part X (i.e. Y has a member variable / subpart / trait X)
I've seen this in GUI toolkits - e.g. someone has a Bitmap class and a ClickableArea class. They want to make a Button - i.e. something that has both Bitmap and ClickableArea traits. So they create Button by inheriting from both Bitmap and ClickableArea classes (usually C++). The better solution is to say that Button has both Bitmap and ClickableArea parts (i.e. member variables). This confusion becomes ridiculously clear if we attempt to create e.g. a Human class by inheriting from Eye, Leg, Arm etc. There is very likely much confusion between all of the members that get dragged in and try to compete with each other.
So, if I have a mistaken view of traits, I would in all honesty love to see an example that shows this to me clearly.
I have a strong view that software should be designed with a very high view of orthogonality. I will often reject non-orthogonal approaches in my own software without much thought, simply because I have been down that road before and seen the trouble that ensues. That's why I would suggest that traits should be rejected IFF they turn out to be a non-orthogonal design (i.e. their utility is duplicated by e.g. member variables). I am not yet convinced one way or the other.