To Traits Or Not To Traits (Was: Re: Stefs roadmap for 3.9, time to get it nailed down)

Cees de Groot cg at cdegroot.com
Wed Feb 23 11:57:08 UTC 2005


On Wed, 23 Feb 2005 00:36:49 +0100, Martin Wirblat <sql.mawi at t-link.de>  
wrote:

> 2) The ongoing attempt of refactoring SystemDictionary seems to be an  
> odyssey without much planning so far. This is not the right way to do a  
> "refactoring" of a kernel part.
>
I think I'm with you there - I've been hunting around over the new  
classes, and I haven't found a consistent pattern so far of what sits  
where. I'm all in favour of cleaning up SystemDictionary (in fact, I'm in  
favour of cleaning it into oblivion ;)), but it looks like there's no  
logical structure about what lands where. Definitely a worthwhile goal,  
but it feels like it needs more direction.

> 3) Traits is a questionable language extension. It is questionable  
> because language extensions to Smalltalk themselves are questionable.
>
Well, that's a bit strong, but

> - What real problem does the language extension/change solve?
>
Is indeed the correct question to ask iff we want to brace ourselves  
against flying off into coolness land (which you assume as a given, I as  
something to be decided upon)

AFAIK, the real problem Traits attempts to solve is about structuring, and  
it looks like me that when you're putting 'library' high on the list of  
itches we should scratch, a cleaner structuring of some ugly bits of the  
base library's hierarchy seems to be one of the things that Traits can  
contribute. It would probably become a whole lot easier to reuse code from  
the base library with a Traitified image (I'm talking from memory here -  
it's been a while since I read the Traits paper so it might be I'm missing  
other strong points).

But the proof of the pudding is in the eating, I think. When there's a  
Traits browser, and the stuff is all a loadable package, people can start  
using it and see whether it solves real-world problems in a way that makes  
it worthwhile to adopt it as a core piece of Squeak.

The only thing I'm afraid of is that we're adding too much friction to the  
process of changing Squeak; as some of the original Smalltalk-80 members  
have complained, the language has become essentially frozen since it left  
the laboratory. For 25 years, it looks like we've missed out on  
opportunities to get this whole OO thingy to higher levels, and I wonder  
whether that's a good thing. I respect these guys a lot, but I don't think  
that they invented the final computer language 25 years ago.

[META]
Grabbing back to the Debian model - maybe we want to have a three-streams  
model. Stable, Testing we've got. What we're missing is Unstable, where  
people are allowed to throw in mostly anything they seem fit. So you can  
actually work with stuff, see how it behaves, before deciding on whether  
to move it on to Testing (which is the doorkeeper to Stable, sort of). The  
Unstable update stream is a good step in this direction, maybe we should  
make it more prominent and push it a little more?
Have some very lightweight 'decision process', maybe a checklist, for  
adding stuff to Unstable?



More information about the Squeak-dev mailing list