Anthony Hannan <ajh18 at cornell.edu> wrote:
> 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,

I am using OO. I have a whole bunch of objects.

> 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

The class for "package" in SM is called SMCard (could be called
SMPackage but the idea from the beginning is that it is not the package
itself - it's more lika a library card for a package).

Ad we actually *do* have a proposal for such an object and it is called
PackageInfo. It has nothing to do with SM though.

> 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 are. Well, except for the fact I don't know what you mean by
"world" image.
But perhaps I just don't understand correctly.

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

Just look at the code for SM and you will see that there is indeed a
model.
and that it does indeed contain objects.

> 	Files should only be used as a means of transport or storage.  And the

I don't use files in the map. Apart from the logfile but that is
equivalent to the Changes file.

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

Now you are talking about the actual packages and not the meta model
about the packages.
Please keep these two things separated in these discussions - IMHO we
need both and they are not the same.

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

I tried to read some PIE paper but didn't get far. Let me be a bit
provocative: If PIE is so very good as so many of you say - where is it?
Stop talking and bring us the goods! :-)

Let me now take a moment and explain some design issues behind SM:

SM is a *catalog* of packages. Not a package repository. This means it
handles metadata about packages and not primarily the packages
themselves. This is a strength because it is package format agnostic -
you can even register a package with just a homepage! But normally you
register a file url for the package.

This also means that SM has objects representing the packages containing
their metadata. This is good because you can then have all metadata
locally for the complete Squeak universe and query this model in many
different ways. If we only had the packages then you would need to load
them all down to your machine in order to examine them and find out the
metadata. That would not be good.

That is also the reason why I want to keep metadata out of the packages
themselves. Some people argue that it is good to have it inside the
package file. I argue almost the opposite. Having it in SM means we can
all have this model handy for queries and we can also *change* the
metadata in some ways independently of the package itself.


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

Cheers, Göran