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