Stephan -

Your write up was interesting.
http://minnow.cc.gatech.edu/squeak/779

If I understand it correctly, you point out that different packages have
different degrees of stability. You use "System Package", "Basic
Package", and "Normal Package" to describe them with ever increasing
degrees of change possible (to the interface). You then propose a
hierarchical approach towards dependency, with things at the root of the
hierarchy being more stable. Thus, a "Normal Package" developed by a
user and in a state of flux may depend on a "System Package" or "Basic
Package", but not vice versa.  Did I get it?

I think this makes a lot of sense. A key insight here is that packages
do have different levels of stability and should be treated differently
based on that.
What's especially good about this approach is it is easily doable by
convention.

One thing possibly implicit in this approach is that there is one common
namespace shared by all packages. That is the case now, so your approach
would be quite good for Squeak as it is. 

The only caveat is that sometimes packages can't be cleanly seperated
into hierarchies. Sometimes this complexity is needed; often it is not.
That is the case with the current Squeak -- and one of the problems with
stripping images (for example, I believe the base Object class has code
related to Morphic, so in what package would "Object" be placed?). In my
opinion the current Squeak should be organized more hierarchically (and
take into account the advice you give).  

ENVY addresses this somewhat by the notion of "extensions"  which are
packages that add methods to classes without defining the class. To load
the extension, you need to first load a package ("application") that
defines the class; this is enforced by the notion of a "prerequisite".

If one has many namespaces, one might in theory have all sorts of
packages with the same name active at once in different name spaces,
with different connections between the packages. So for example, if you
are working on a "System Package" in one name space, you might need to
change it, and yet want your browsers and debugger to be using the
un-modified version of that "System Package". 

However, multiple namespaces does not invalidate your concept -- it just
enhances it. One should still structure interdependencies along the
lines you propose of [more stable] <- [less stable] when possible.

In any case, good insight!

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

Stephan Rudlof wrote:
> 
> Some time ago I have written down some thoughts (with great ASCII
> graphics! ;-) ) about structuring packages titled
>         Structuring packages to minimize 'bad' dependencies
> in
>         http://minnow.cc.gatech.edu/squeak/779
> .
> 
> I would like if someone would take a look onto it...
> 
> Greetings,
> 
> Stephan
> 
> PS.: Don't mix me up with one of the other Ste*an*'s...