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
|