Paul,

thank you for your comments. Some more from me:

Paul Fernhout wrote:
> 
> 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?

Yes.

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

It's not so easy, since it is difficult to get *acceptance* of a new
convention.

> One thing possibly implicit in this approach is that there is one common
> namespace shared by all packages.

Namespace are another topic, but in general good to ease modularization.

> That is the case now, so your approach
> would be quite good for Squeak as it is.

Introducing a package hierarchy is possible with or without namespaces.
But without namespaces the probability of name conflicts is higher.

> The only caveat is that sometimes packages can't be cleanly seperated
> into hierarchies.

That's an interesting point.
I'm in doubt about this. I think it should be possible to separate
packages cleanly. But this seems to be a good point for further
discussions!

There could be problems if the functionality of two packages contradicts
in some kind: e.g. event versus polling oriented Controllers. So there
could be complicated constraints which are more than just code
dependencies.

> 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?).

I think the core of Object (with its class definition) would be placed
in the SystemPackage 'Core', but e.g. Morphic specific methods in Object
could be placed in a BasicPackage 'Morphic', which itself depends on the
SystemPackage.

> 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".

This goes into the right direction.

> 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".

There is some similarity to isolated projects.

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

Main points for a package are
- the separation of *interface* methods from the implementation part;
- the compatibility of the *interface* methods of newer to previous
versions;
- a definition of the dependencies from other packages (prerequisites),
here multiple dependencies are possible (possibly also mutual ones).

The first point is difficult, because it needs some discipline of the
programmer and isn't forced by the ST language/system. Probably tools
could help here.

> In any case, good insight!

:-)

Greetings,

Stephan

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

-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3