Göran,

> So... please tell me that I am paranoid and that the above will not
> happen. :-)

You are paranoid and it will not happen ... if and only if a gradual model
of adoption can be developed. That's the key point (always has been). If
there is a gradual path to transitioning into this universe, one in which
people can safely try out the advantages of the approach then it's simple -
just declare traits as a prerequiste for your stuff and start using it. 

The problems you describe only happen if everyone is forced to buy into some
new technology while it is still in flux (such as happened with modules).
Gradual adoption also has advantages for the developers of the new
technology - it allows them to see how their stuff is used in practice,
learn from it and get to the next level. 

For example, I am certain that Nathanael would like to learn more about the
practical implications of a wide-spread use of traits. While everyone in
Berne probably understands the model it's always slightly different when
things get out into the hands of the unwashed masses (no offense meant - in
the case of traits, I consider myself to be part of it).

Here is what I would propose for the particular case of traits: Define the
fundamental invariants upon which the traits support relies as "frozen" - no
changes will be done in those (probably very few) areas in which the traits
support hook in. Possibly, do some slight modifications of the Squeak kernel
in order to provide a documented hook for traits support. For example, I
think that traits require some extensions to ClassDescription and those
could make it to the Squeak kernel. Then, the ground is set so that people
can easily install traits into their system without fearing to break
anything. The developers of the model know which hooks they can rely on,
which invariants *will* be supported by the Squeak kernel as of version X.
Knowing Nathanael, I am pretty sure he can pin-point those places that need
to be frozen in order to support the traits model easily. [Incidentally:
This is the exact model that the VM uses for JIT support - it provides about
ten entry points into which a JIT can hook and those are all that's needed
and that a JIT can rely upon].

I can put this into simpler terms if you want: Make it so, that traits can
be trivially installed if wanted. Make it so that the absence or presence of
traits does not fundamentally break the system. Make it so that it is clear
where the intersection of the system with traits lives (so that, for
example, modifications to system-level aspects can be done knowing whether
it will interfere with traits or not). Make it so that users of traits can
simply declare the need for traits as a prerequisite for "their stuff". If
that means we need to do a few modifications to the Squeak kernel then let's
do that. Having worked with Nathanael, I trust him to bring the traits model
to a point where the value to the community is obvious (he's just a
perfectionist ;)

A much harder, yet completely independent question is whether to apply some
of the existing refactorings (such as collections) right away. My essential
feel here is: Don't. Traits "ought" to be able to provide value outside of
just those refactored places and if that's the case, then we should start
out using them wherever we want. The existing refactorings still provide
value in such that they are examples of what you can do with the system,
where and how one would use traits. However, whether collections are
implemented using traits or not does - for a user of Squeak - not matter. As
long as collections understand the right protocol, everything is fine. Using
this model, e.g., for the time being not apply any refactorings to critical
places of the system buys all of us time to judge the implications, to find
out where and how to use traits, to learn and see how it works out (both,
for users and developers of traits).

At the point where a significant number of developers *do* understand the
value and the advantages of traits, we will have a trained set of people who
could (if it ever comes to that) support the model "without living in
Berne". Those people are likely to raise the point that it's quite stupid to
require traits for about every interesting bit of code in the community, but
have the kernel places not use them. That would be the time by which those
refactorings can be applied easily - and I'm pretty sure that at this point,
the questions you are raising won't even come up.

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of goran.hultgren at bluefish.se
> Sent: Sunday, February 16, 2003 3:00 PM
> To: The general-purpose Squeak developers list
> Subject: Re: Two important issues...
> 
> 
> Standing on the side here...
> 
> A few of the postings from Stephane has probably
> mistakenly/unintentionally sounded like "Ok, Squeakers - either you do
> this and this or we will leave...". I understand Jim's reaction, but I
> don't think it was intentional from Stephane.
> 
> Ok. But there is indeed one important thing to note here - 
> and please -
> these are just my personal reflections.
> 
> As one of the people committed to Squeak I would not like us to adopt
> technology that will really affect Squeak to the core - if not the
> principal people behind that technology is devoted to Squeak 
> and to the
> community and will "hang on even if the road gets bumpy". What am I
> trying to say? Well, I would really hate the following scenario:
> 
> 1. The community adopts Traits (still a long term gradual thing of
> course). Nathanael is AFAIK the principal engineer behind the code.
> Perhaps this stuff is so complex and to the core of Squeak that few
> others can help out and/or maintain it.
> 
> 2. Along the way "the guys in Bern" decide that, nah - Squeak 
> wasn't the
> proper vehicle for our research. It may be due to some choices in the
> community that doesn't turn out to the liking of "the guys in 
> Bern" - or
> whatever. And "the guys in Bern" simply jumps off the ship and start
> using Smalltalk-younameit instead.
> 
> And then here we are, left with a system we don't understand, with a
> halfbaked new browser/parser etc. etc. That wouldn't be good. It could
> all turn out similarly to 3.3alpha (even if it would be partly due to
> other reasons) where we ended up with a halfbaked system we couldn't
> move forward.
> 
> So... please tell me that I am paranoid and that the above will not
> happen. :-)
> 
> regards, Göran
> 
>