SM future version

Colin Putney colin at whistler.com
Fri Nov 22 03:58:33 UTC 2002


Not to keep beating a dead horse, but again, the important thing in all 
this is to make these changes incrementally. The packaging strategy 
we're pursuing right now is completely orthogonal to the existing 
mechanisms for organizing the image.

The fact of the matter is that package design is easy. There's PIE, 
ENVY, Ginsu, Henrik's Modules, VW packages/parcels etc. They all have 
their pros and cons, and we could choose one or invent our own; it 
doesn't matter. The hard part is actually carving up the tangled mass 
of existing code that's currently in the image and free floating 
changesets. The really, really hard part is using the system for your 
day-to-day work WHILE you're doing the hard part.

A more elegant package model will come in time. But there's no point in 
having one if we can't adopt it.

Cheers,

Colin

On Wednesday, November 20, 2002, at 09:21  PM, Anthony Hannan wrote:

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




More information about the Squeak-dev mailing list