<br><font size=2 face="sans-serif">Hi Stéphane,</font>
<br>
<br><font size=2 face="sans-serif">Yes, I ***really*** do think that the Collection hierarchy is a "toy" example. Allow me to explain why:</font>
<br>
<br><font size=2 face="sans-serif">What was done with the Collection hierarchy was essentially a refactoring to use Traits. It wasn't a new design from requirements. And while the Collection hierachy is a fabulous and powerful invention, it is really just a bunch of generic components to be used in building more complex systems.</font>
<br>
<br><font size=2 face="sans-serif">My point was that I don't think that the capabilities Traits offers matches up with the way that commercial software is created in the "real" world.</font>
<br>
<br><font size=2 face="sans-serif">I work on a product that is built from over ten thousand source files and has hundreds of developers working on it. The system runs on at least 8 different target CPU's (obviously, not all of the code runs on all eight different CPU types), and includes code written in C, C++, Java, JavaScript, Pascal, various assembly languages, and includes over 300 megabytes of executable code. I am not commenting on the quality of code, only the quantity here. The quality level of the code by any objective standards varies widely, depending on the skill and experience of the people who worked on it and the other constraints placed on the development (i.e. if we can't demonstrate the new feature to an important customer by the end of the (pick some time interval - quarter, month, week, etc.) we will lose a sale worth millions to an evil competitor).</font>
<br>
<br><font size=2 face="sans-serif">I think what I am describing here is how a lot of software gets created in the real world, and in this kind of environment the code never gets past the "make it work" stage. "It works - ship it, and get on to the next thing" tends to be the approach. My point is that common behavior that COULD be reused and benefit from Traits is not usually identified until quite late in the game, after a lot of code has already been written, if it can be identified at all.</font>
<br>
<br><font size=2 face="sans-serif">The other idea that I was trying to get across is that code reuse is a double-edged sword. While it can reduce maintenance effort, and improve the overall quality of a code base, it also makes the codebase more brittle by introducing heavily loaded single points of failure.</font>
<br>
<br><font size=2 face="sans-serif">So I guess I am raising a largely philosophical issue. As I understand it, Traits facilitates code reuse in ways that would be difficult if at all possible with a single inheritance class hierarchy. This capability comes at the cost of an extra layer of complexity (or degree of freedom, if you prefer) and possibly a decrease in performance. The philosophical questions are how can I use it, and how will I benefit from having used it?</font>
<br>
<br><font size=2 face="sans-serif">The Collection hierarchy example shows that I can implement 27 classes with 48 Traits, saving about 10% in the number of methods. This says to me that there was only an average of 2 or 3 methods per class that were redundant or refactorable (Given that we end up with 567 methods, this implies 630 methods in the original implementation, so we eliminated about 63 methods). So, in this respect I don't think that the Collection hierachy is a very strong example for showing the benefits of Traits. You had my attention more with the RectangleMorph example. There you were going to save 70 methods with only 3 classes involved.</font>
<br>
<br><font size=2 face="sans-serif">Admittedly, the paper that is dedicated to the Traits based Collection class hierarchy goes into more detail and shows a greater savings in method count, but I am not sure if I agree that counting (m+h) is legitimate, so I will call it 17.7% instead of 28.2%.</font>
<br>
<br><font size=2 face="sans-serif">I did read the papers, but like many good papers they generate at least as many questions as answers. Traits is very "blue plane" stuff and therefore interesting, but we've had single inheritance for over thirty years, and most of the world still doesn't take advantage of the capability that it brings. I approach Traits with trepidation because it offers another way to do things and I do think there is such a thing as too much flexibility. That was/is one of the major problems with C++.</font>
<br>
<br><font size=2 face="sans-serif">So I guess I'm still looking for somebody to show me the "good-ness" of Traits, because so far it looks interesting, but like a lot of work for a small increase in code reuse and a (hopefully) small decrease in performance, and we've been seeing a "small" decrease in performance with each successive version of Squeak for way too long now. This is (of course), only my opinion. I could certainly be in the minority here.</font>
<br>
<br><font size=2 face="sans-serif">Traits shows clear value in refactoring, but refactoring is "code cleaning", and it doesn't happen much in the real world. In fact, it is sometimes "forbidden" because it is seen as a high risk to touch code that is "field proven".</font>
<br>
<br><font size=2 face="sans-serif">So for now I will sit back, watch, and try to learn something.</font>
<br>
<br><font size=2 face="sans-serif"> -Dean</font>
<br>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>stéphane ducasse <ducasse@iam.unibe.ch></b></font>
<br><font size=1 face="sans-serif">Sent by: squeak-dev-bounces@lists.squeakfoundation.org</font>
<p><font size=1 face="sans-serif">08/30/2005 09:37 AM</font>
<br><font size=1 face="sans-serif">Please respond to The general-purpose Squeak developers list</font>
<br>
<td><font size=1 face="Arial"> </font>
<br><font size=1 face="sans-serif"> To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org></font>
<br><font size=1 face="sans-serif"> cc: </font>
<br><font size=1 face="sans-serif"> Subject: Re: Traits approaching mainstream Squeak</font></table>
<br>
<br>
<br><font size=2 face="Courier New">Hi dean<br>
<br>
do you ***really*** think that the Collection hierarchy is a toy <br>
example....<br>
I'm not sure that we are talking about the same.<br>
<br>
On 30 août 05, at 02:28, Dean_Swan@Mitel.COM wrote:<br>
<br>
><br>
> While I find all this discussion fascinating, I would like to share <br>
> a few thoughts on the idea of including Traits in mainstream Squeak.<br>
><br>
> My first concern is performance. Since Traits carry no state, they <br>
> will need to use accessor methods and message sends are clearly <br>
> much slower than direct instance variable access.<br>
><br>
> My second concern is regarding how Traits should/could/would be <br>
> used. All of the examples that I have seen so far, including the <br>
> refactoring of the Collection hierarchy, seem to me to be "toy" <br>
> problems. I would be interested to read about non-trivial cases <br>
> where Traits would solve a significant real world problem.<br>
><br>
> It would seem to me that the kind of reuse that Traits enables is <br>
> the kind that isn't apparent at design time, since individual <br>
> classes of object are usually designed separately and often by <br>
> completely different people. The common behavior and opportunity <br>
> for code reuse might only become apparent after the initial design <br>
> is implemented. It has been my experience that once something is <br>
> implemented and working, unless there is a compelling reason to <br>
> justify it, the code is never revisited. Management is generally <br>
> focused on allocating resources to things that will yield either an <br>
> opportunity for increased revenues, or reduced costs, and code <br>
> "cleaning" is rarely viewed as either. If it ever gets done (code <br>
> cleaning), it is usually silently piggybacked on required bug fixes <br>
> by individual developers who feel it is important. Am I in the <br>
> minority here, or is this how commercial software development works <br>
> in general?<br>
<br>
<br>
Cleaning your design does not solve the problem that traits solve.<br>
Read the papers. Sometimes we are forced to duplicate code or to <br>
write a lot of delegate methods just because we cannot simply reuse<br>
method dictionary. This is what traits are about.<br>
<br>
> I would even suggest that single inheritance doesn't get used that <br>
> much in practice. I see an awful lot of C++ where classes are root <br>
> classes and implement a singleton object. I see poly-morphism used <br>
> a lot, but not much inheritance. I also see STL used a lot to get <br>
> common syntax container objects, that you get with the standard <br>
> Smalltalk Collection hierarchy anyway.<br>
><br>
> So I guess I don't see what Traits gets us that we can't already do <br>
> in Squeak with some judicious use of proxies, DNU and separate <br>
> "behavior only" and "state only" classes using accessors for all <br>
> instance variable access. Is the real benefit in having tools that <br>
> formalize this and make it easy?<br>
><br>
> Is Traits implemented by just pointing a class's method dictionary <br>
> entries to the approprate seemingly class-less compiled method <br>
> defined in a Trait?<br>
><br>
> I guess I don't fundamentally oppose including Traits in mainstream <br>
> Squeak, as long as it's still possible to ignore it and it doesn't <br>
> cause a decrease in performance for commonly used objects (i.e. the <br>
> Collection hierarchy). From what I've read in the whitepapers, it <br>
> seems it should be safe and easy to ignore, so the only question I <br>
> guess would be performance.<br>
><br>
> And lastly I will just say that as others (Andreas) have pointed <br>
> out, maximising code reuse is not always desirable. I can see the <br>
> argument in favor of code re-use to propagate common behavior <br>
> without having to find every duplicated variation, but there is <br>
> also the other side of the argument where a single bug in a common, <br>
> highly reused method can cause a lot of things to break that might <br>
> otherwise work properly.<br>
><br>
> -Dean<br>
><br>
><br>
<br>
</font>
<br>
<br>
<br>