Traits approaching mainstream Squeak

goran at krampe.se goran at krampe.se
Thu Sep 1 10:42:37 UTC 2005


Hi all!

I don't have much time to write but just a few of my personal views
after having read some of this thread:

The use of inheritance in Smalltalk is kindof interesting - is it about
normalizing (minimizing duplication) implementation or is it used to
model ISA relationships (types)? On one hand it defines instvars etc,
which definitely is implementation and not "type related", and on the
other hand all the messages are inherited which definitely is "type
related" (think protocols) - but protocols are orthogonal to class in
Smalltalk (given its type sytem) so it really is a bit unlogical that
they are also inherited in the class hierarchy.

As Trygve notes inheritance is quite nice in "reasonable doses", but in
heavy doses it easily gets out of hand (think Morphic).

One aspect people often tend to forget is that since inheritance
strongly couples the subclass with its superclass (and all superclasses
all the way up of course) there is another aspect that needs to be taken
into account: life cycle of code development.

What I mean with that is that if the superclasses are likely to change
(or not be able to change for that matter) over time in a manner that
isn't aligned with the subclass - then the inheritance is unsound - no
matter how tasteful the ISA relationship looks. :) One example of this
is SocketStream (the old one) that inherits from... Stream IIRC. Sure,
looks tempting, but it simply ISN'T a Stream in that sense (hey, it is
bidirectional for starters), and the inherited protocols brought more
problems than benefits IMHO. In FastSocketStream (now in 3.9) I chose to
simplify it and just inherit from Object - that gave me full control.


Anyway, my view regarding Traits:

1. The current model in Smalltalk (class single inheritance) is a nice
balance between being sufficient for a large part of the problem
domains, and still quite simple to grok. Time has proven that. But it
*definitely* has problems - one perfect example is again Morphic,
hehe... ;)

2. Traits seems very nice in all respects. It is a clean model, it is
backwards compatible in all useful senses, it has devoted developers and
it really does seem to make people smile when they understand it (OOPSLA
BOF comes to mind, people were ecstatic). It is one of the most concrete
and promising evolutions in the OOP field I have seen at least. It both
puts a focus on protocols (just like the Java people did with their
interfaces - which is a good thing in itself - it makes them much more
tangible and visible) and gives us a new way of composing implementation
of behavior which probably will end up changing the way we work, at
least that is my guess. I can easily see myself starting to identify and
code up Traits for behavioral composition (instead of class inheritance)
and then use class inheritance almost solely for inheriting structure
(instvars).

3. Squeak needs to move forward into the future. It has been "a
Smalltalk" for quite some time now, and while that is nice we really
need to stop worshipping "Smalltalk" as something unimprovable. So come
on people, let's go for it, what do we really have to lose?

We need to start moving and shaking again, and it seems to me that the
newer processes slowly coming into place (Monticello based development
etc) actually will give us a lot in this respect.

So my suggestion is that we simply decide to "try it" (traits) and see
where it leads us, sure, it will have its rough spots in the beginning -
and so will the new Compiler framework - but these things are so very,
very nice that we really can't let us stop us IMHO.

regards, Göran



More information about the Squeak-dev mailing list