Traits approaching mainstream Squeak

Dean_Swan at Mitel.COM Dean_Swan at Mitel.COM
Wed Aug 31 00:21:28 UTC 2005


Hi Stéphane,

Yes, I ***really*** do think that the Collection hierarchy is a "toy" 
example.  Allow me to explain why:

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.

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.

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

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.

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.

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?

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.

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

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

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.

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

So for now I will sit back, watch, and try to learn something.

                -Dean






stéphane ducasse <ducasse at iam.unibe.ch>
Sent by: squeak-dev-bounces at lists.squeakfoundation.org
08/30/2005 09:37 AM
Please respond to The general-purpose Squeak developers list

 
        To:     The general-purpose Squeak developers list 
<squeak-dev at lists.squeakfoundation.org>
        cc: 
        Subject:        Re: Traits approaching mainstream Squeak


Hi dean

do you ***really*** think that the Collection hierarchy is a toy 
example....
I'm not sure that we are talking about the same.

On 30 août 05, at 02:28, Dean_Swan at Mitel.COM wrote:

>
> While I find all this discussion fascinating, I would like to share 
> a few thoughts on the idea of including Traits in mainstream Squeak.
>
> My first concern is performance.  Since Traits carry no state, they 
> will need to use accessor methods and message sends are clearly 
> much slower than direct instance variable access.
>
> My second concern is regarding how Traits should/could/would be 
> used.  All of the examples that I have seen so far, including the 
> refactoring of the Collection hierarchy, seem to me to be "toy" 
> problems.  I would be interested to read about non-trivial cases 
> where Traits would solve a significant real world problem.
>
> It would seem to me that the kind of reuse that Traits enables is 
> the kind that isn't apparent at design time, since individual 
> classes of object are usually designed separately and often by 
> completely different people.  The common behavior and opportunity 
> for code reuse might only become apparent after the initial design 
> is implemented.  It has been my experience that once something is 
> implemented and working, unless there is a compelling reason to 
> justify it, the code is never revisited.  Management is generally 
> focused on allocating resources to things that will yield either an 
> opportunity for increased revenues, or reduced costs, and code 
> "cleaning" is rarely viewed as either.  If it ever gets done (code 
> cleaning), it is usually silently piggybacked on required bug fixes 
> by individual developers who feel it is important.  Am I in the 
> minority here, or is this how commercial software development works 
> in general?


Cleaning your design does not solve the problem that traits solve.
Read the papers. Sometimes we are forced to duplicate code or to 
write a lot of delegate methods just because we cannot simply reuse
method dictionary. This is what traits are about.

> I would even suggest that single inheritance doesn't get used that 
> much in practice.  I see an awful lot of C++ where classes are root 
> classes and implement a singleton object.  I see poly-morphism used 
> a lot, but not much inheritance.  I also see STL used a lot to get 
> common syntax container objects, that you get with the standard 
> Smalltalk Collection hierarchy anyway.
>
> So I guess I don't see what Traits gets us that we can't already do 
> in Squeak with some judicious use of proxies, DNU and separate 
> "behavior only" and "state only" classes using accessors for all 
> instance variable access.  Is the real benefit in having tools that 
> formalize this and make it easy?
>
> Is Traits implemented by just pointing a class's method dictionary 
> entries to the approprate seemingly class-less compiled method 
> defined in a Trait?
>
> I guess I don't fundamentally oppose including Traits in mainstream 
> Squeak, as long as it's still possible to ignore it and it doesn't 
> cause a decrease in performance for commonly used objects (i.e. the 
> Collection hierarchy).  From what I've read in the whitepapers, it 
> seems it should be safe and easy to ignore, so the only question I 
> guess would be performance.
>
> And lastly I will just say that as others (Andreas) have pointed 
> out, maximising code reuse is not always desirable.  I can see the 
> argument in favor of code re-use to propagate common behavior 
> without having to find every duplicated variation, but there is 
> also the other side of the argument where a single bug in a common, 
> highly reused method can cause a lot of things to break that might 
> otherwise work properly.
>
>                 -Dean
>
>




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20050830/df2ffd97/attachment.htm


More information about the Squeak-dev mailing list