Two important issues...

goran.hultgren at goran.hultgren at
Fri Feb 14 12:22:54 UTC 2003

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

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
======== 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

More information about the Squeak-dev mailing list