[squeak-dev] My view on Traits

Ryan Mitchley ryan.mitchley at gmail.com
Fri May 16 08:52:57 UTC 2008


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

-- 
View this message in context: http://www.nabble.com/-squeak-dev--My-view-on-Traits-tp17257352p17270291.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.




More information about the Squeak-dev mailing list