Comments on the topic of "what are traits good for?" from Nathanael,
forwarded from Pharo list. This is in response to the question raised
on this list a while back.

Dave

----- Forwarded message from St?phane Ducasse <stephane.ducasse at inria.fr> -----

From: St?phane Ducasse <stephane.ducasse at inria.fr>
Date: Tue, 5 Jan 2010 19:23:08 +0100
To: "Pharo-project at lists.gforge.inria.fr Development" <Pharo-project at lists.gforge.inria.fr>
Subject: [Pharo-project] Fwd: traits :)
Reply-To: Pharo-project at lists.gforge.inria.fr


Some emails about traits from their father @ google :)

> Hi Stef
> 
> Sorry for the late reply. I'm just going through my email after the Christmas break...
> 
> > Could someone please come up with ONE example where MI (traits in particular) solve an *actual* problem and not just some academic BS?
> 
> I have encountered a bunch of cases in my every-day work at Google where single inheritance was not good enough to write the functionality that we needed without (a) code duplication and/or (b) boilerplate for object delegation (plus the associated complexity/slow-down/etc.). This was getting so annoying that I went through the hassle of implementing a template-based traits mechanism in C++ that we have been using quite regularly.
> 
> For example, we have been designing and implementing a very complex framework for efficient handling of massive entity/relation graphs (billions of nodes). Since we needed this framework to be general across multiple aspects, we simply couldn't come up with a good way of doing this without some sort of MI, and traits proved to be extremely useful. So, based on my experience, I certainly have seen plenty of real-world applications where traits can make a tremendous difference!!
> 
> That said, I can absolutely see that an overuse of traits can also add a lot of additional complexity. But in my opinion, this is not specific to traits and much more applies to almost any concept when it is overused. Consider for example single inheritance. If someone needs a class with 50 methods and decide to split this into a 10-level deep class hierarchy (just in case that somebody might want to reuse a part of it later), this will annoy a lot of other people and make things unnecessary complex. Similarly, if somebody splits a method with a 20 line algorithm into 10 helper methods with hard-to-understand names and consisting of only 2 lines each, this will probably make things much harder to understand (although having small methods is generally a good thing).
> So, despite the fact that the concepts of single inheritance and (helper-)methods can be overused, I'm sure that neither of us would argue that they are bad/useless in the first place. And this is the same for any of the other nice programming concepts that come to mind, like meta-programming and closures (as much as I love closures for parametrization, overuse of functional elements can make code really hard to understand as well...)
> 
> From my point of view, the same applies to traits: If traits are used in cases where they actually bring a benefit, i.e., they factor together a set of methods that conceptually and logically belong together and actually facilitate code reuse, they have been very useful to me.
> 
> 
> Happy New Year and all the best,
> Nathanael
> 





_______________________________________________
Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

----- End forwarded message -----