Goran,

> Personally I do think it could be placed in core. It seems to 
> be such an elegant extension solving a lot of problems. But 
> some people probably wants Squeak to stay as a "Smalltalk 
> clone" and be as compatible with other Smalltalks as 
> possible. Well, I am not one of them - but it will be 
> interesting to see the discussion unfold.

I think that this is quite a fundamental question. Since traits are only
available as a more or less stable prototype version at the moment, we
don't have to take a decision right now, but it never hurts to talk
about it in advance.

I also think that it would be helpful for you to know our future (Stef,
Roel, Alex and me) plans regarding traits. So here they are:

- As I said before, the current model of traits is just a first step. We
have very concrete and exciting ideas of a second version of the model
that is much more powerful than what we have now. Because we want to
validate this new model in practice, we are definitely going to
implement it on top of Squeak, SqueakScript or possibly another
Smalltalk implementation. At the end of next week, Andreas Raab is
visiting our lab, and then we will talk with him and take a decision
regarding the platform.

- Once this is decided, we are going to do a _clean_ implementation of
this extended traits model. Since this new model is a completely
downwards compatible extension of the current model, the new
implementation will also serve as the basis for a clean and stable
implementation of traits as they are now.

Cheers,
Nathanael

> -----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: Freitag, 14. Februar 2003 13:23
> To: Squeak-dev at lists.squeakfoundation.org
> Subject: Two important issues...
> 
> 
> Hi all!
> 
> I thought this list was so "quiet" so I just had to start a 
> new thread... :-)
> 
> There are two (well, 723 to be exact, but these two are 
> interesting) issues we really need to start discussing:
> 
> 1. Package grouping/blessing, package ownership, allowed 
> dependencies etc.
> 
> 2. Traits.
> 
> In different threads the last days we have been discussing 
> how to prevent chaos when we start tearing the image to 
> pieces and putting stuff on SqueakMap instead.
> 
> Sidenote: We might want to wait a bit until *really* removing 
> packages from the image - at least until SM1.1 is out. There 
> are a bunch of good reasons for that.
> 
> Issue 1
> ========
> 
> ...is about how we should group our packages. Here are a few 
> suggestions:
> 
> Core packages - these are typically packages currently in the 
> base image and they more or less constitute what we like to 
> call "Squeak". We will probably have different "rules" for 
> how to maintain these - higher standards, cooperative 
> ownership etc, what do I know. Packages in core can only 
> depend on other packages in core of course.
> 
> Extra packages - these are packages not regarded as core but 
> nevertheless packages that applications etc tend to rely on. 
> They are typically personally owned and maintained but the 
> maintainer is aware of the fact that the package is important 
> to many others. But they aren't core - so some relaxation 
> exist. Packages here can depend on both packages in core and in Extra.
> 
> Core replacements - these are packages that can not coexist 
> with one or more packages in core. A Morphic replacement 
> would typically be here. Depending on one of these packages 
> is obviously quite risky and would greatly increase the risk 
> of conflicts with other packages. Experimental rewrites of 
> core packages will live here until they can actually step 
> into core and replace the old packages. Packages here can 
> depend on both packages in core and in Core replacements. But 
> when moved into core they can of course only depend on 
> packages in core.
> 
> Normal packages - well, the rest. :-) Here we have all the 
> applications, tools, you name it. They can depend on packages 
> in all other groups. Depending on packages in Core 
> replacements is on the other hand a pretty dicy thing of course.
> 
> Ok, that probably got your brains in gear... This is a very 
> important question for us to sort out. Implementation is on 
> the other hand very easy - we simply add a few categories on 
> SM for grouping. So, shoot.
> 
> 
> Issue 2
> ========
> 
> Issue 2 is somewhat peripherally connected to the above. 
> Traits is standing outside our pretty little Smalltalk-80 
> descendant house and is knocking on the door. What does this 
> mean? If Traits was a package - where should we put it? In 
> core? Ok, that would essentially mean that Squeak is taking a 
> step away from Smalltalk. Squeak simply isn't a "Smalltalk-80 
> clone" anymore. And the argument that Traits is optional to 
> use doesn't hold - people *will* use it and that will change *a lot*.
> 
> Personally I do think it could be placed in core. It seems to 
> be such an elegant extension solving a lot of problems. But 
> some people probably wants Squeak to stay as a "Smalltalk 
> clone" and be as compatible with other Smalltalks as 
> possible. Well, I am not one of them - but it will be 
> interesting to see the discussion unfold.
> 
> What if we put Traits in "Extra" then? Sure, that is a 
> compromise that may work. But then we will loose a lot of the 
> real good use of Traits - to untangle our core packages like 
> for example Collections or Morphic. Because we can't have 
> packages in core depending on packages outside of core. So 
> that doesn't really sound like an interesting option.
> 
> So, again - a very interesting challenge I think. Are we 
> going into the future or are we staying in the eighties? :-) 
> Can we do both?
> 
> Well, fire away. But let's keep it civil. ;-)
> 
> regards, Göran
> 
>