Two important issues...

cg at cg at
Sat Feb 15 09:27:51 UTC 2003

Swan, Dean <squeak-dev at> said:
>Just to voice my opinion, I agree with Daniel on this.  I feel like I
>want somebody to convince me that Traits is something I need.
Define 'need'. When people talk about 'need' in a programming language
you quickly get to the Turing completeness argument, and that's boring. 

The choice is simple economics: will inclusion of Traits return
more value than the cost of inclusion? The cost is clear: at this moment
it *looks* like a move away from 'mainstream Smalltalk-80'; but note
that this happens all over the place: lots of VW code doesn't file in
because of their namespaces, look at all the changes in S#, etcetera.
The benefits are unknown, but generally believed to be big. 

>I don't really understand Traits too well at this point, but I agree
>with Daniel that it seems to be of greater value for refactoring
>existing code than it is for writing new code.
Have you read the papers? I think they are quite good in explaining
traits. Generally, I would hope that any people mixing in in this
discussion have read the papers, then tried it, then tried to resolve
all the questions, before starting to hand out opinions on whether
to include it or not...

>I understand
>subclassing and overriding a method from a superclass.  Traits is more
Hardly. And anyway, there was a time you didn't understand subclassing.
You've apparently learnt to understand it. 

>I would hate to see Squeak/Smalltalk gain as much "flexibility" as
>something like C++.  Will Traits make it any easier to do ill-advised
>things (i.e. write bad code)?
I think the first argument is a good one. The second less so. Yes, we
must be sure that we don't make it too easy to extend the language and
end up with a baroque monstrum like C++. 

However, Traits is not about some neat feature coming out of the blue.
If there is anything that most single-inheritance and
multiple-inheritance proponents agree on, is that there might be a
middle ground satisfactory to both parties and probably even better than
either 'extreme'. Traits is a proposal to bring Squeak to that middle
ground, in a way that a lot of people think is better than any of the
current alternatives (like mixins, or MI+saying-you-shoulnd't-do-X,

>I am not saying that Traits should never be a "CORE" package, but IMO it
>is  FAR to early for it to even be considered for that yet. 
If you're talking about filing in the code now and calling it 'Core',
yes. But I hardly think that this would be the case. It'd be more like
deciding 'this is the direction to move in', add it into the current
(development) image, and have people hammer on it for the better part of
a year..

I agree about the desirability of taking up a real project with it.
However, it is an unrealistic demand. If people were to put an awful lot
of time into refactoring, say, Morphic or all of Squeak's collections,
they'd demand the work be used. It is unfair to ask for such a large
investment in an Open Source project. I think that the Collections
refactoring is a good example of a real life class hierarchy and how it
can be cleaned up with Traits, and what we need to do is probably look
at our own projects, extrapolate how they'd look with Traits, and make a
decision based on that.

Cees de Groot          <cg at>
GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B
Cogito ergo evigilo

More information about the Squeak-dev mailing list