goran.hultgren at bluefish.se wrote:
> This post is LONG, but it explains how I intend to deal with
> dependencies in SM.

Goran and other package enthusiasts, I'm afraid we are not practicing
what we preach.  What I mean is, even though we promote
object-orientation for all systems, we are not using object-orientation
for our own packaging system.  In particular, we are creating packages,
configurations, etc. but they are not objects.  We still don't have a
Package or Module class, or even a proposal for one.  Just because
Henrik's Module class did not work it does not mean we should abandon
object-orientation.  The closest thing we have to a package class is
ChangeSet, but it does not have prerequisite or version behavior, nor is
there talk about adding those behaviors.  To put it another way, all
packages, configurations, versions, etc. in the Squeak world should be
objects, capable of living together in the same SqueakMap "world" image.
 They don't all have to be active/installed, but they should all be live
objects not files.  Objects are not only easier to query and edit in
Squeak, but more importantly, they are easier to model.  The package
design will be a lot easier and clearer if we think and talk in terms of
objects.
	Files should only be used as a means of transport or storage.  And the
best file format is probably the image segment format because it is the
fastest to create and load, although others will work as well (Smalltalk
chunk format, XML, SAR, etc).
	Finally, with regard to the actual package design, I strongly suggest
the PIE [1] design or something similar.  It also serves as an example
of an object-oriented design.  In PIE terminology, I think of layers as
packages, and contexts as configurations.

Cheers,
Anthony

[1] http://www.dolphinharbor.org/docs/PIE%20Layered%20Approach.pdf