On Wed, 16 Oct 2002, [ISO-8859-1] G=F6ran Hultgren wrote:

> Ok, what about all you other people out there? Are my explanations making=
 any
> sense? Henrik - could you please acknowledge that I haven't made any gros=
s
> factual errors? Daniel, what do you think?
>
> I continue to stand by the Modules codebase as a good start, but I am alw=
ays
> open for improvements.

It seems to me that part of the problem with these discussions of modules
is that nobody has been terribly clear about what they hope to get out of
them.  Perhaps if we make our goals clearer, it will be easier to talk
about the possible solutions.  Here are a few things that I would think a
module system might provide:

1. A way to specify related pieces of code.  This has to
include both entirely new classes and patches/additions to existing
classes.  Let's call these "packages".
2. A way to easily save and load these packages to and from easily
distributable files.
3. A way to cleanly update an image with a new version of a package.
4. A way to cleanly unload a package from an image.
5. A way to analyze dependencies between packages.
6. A way to specify dependencies between packages.
7. A way to protect packages from name clashes.
8. A way to organize packages hierarchically.

IMO, 1-3 are the most important.  Not surprisingly, these are also what
DVS mostly provides, although it works better for straight additions to
existing classes than for patches to them.  The interesting thing is that
this can be provided without any changes to the base image, as a simple
addon package.

4, I think, could also be done fairly easily on top of 3.2, but it seems
much less important to me: once I've loaded something into an image I
rarely want to remove it.  If I'm testing a new package, I use a throwaway
image.  I guess that assumes a minimal base image to load things into.

Daniel has already done 5, again in 3.2.  I don't see why 6 would be very
difficult - it ties into what Daniel and I were talking about with
subclasses of Module to store metadata.  6 also seems like something that
SqueakMap might be extended to do.

7 is, of course, the big one: it is the real justification, as far as I'm
concerned, of the work that's beem put into 3.3a.  But how big a deal is
it?  Are people routinely struggling with naming conflicts?  I tend to
throw a 2 letter prefix in front of my class names and forget about it.
But maybe that's just me.

8 would be nice, but the major benefits (being able to load/unload groups
of packages at once) can be gotten through dependecies + dummy packages,
the same way most of the linux packaging systems work.

This is a highly personal take on things, of course - I'm not
pretending that these preferences will be the same for everyone.  I'd
be curious to hear what, for example, Stef's or Henrik's version of
this list would look like.  But me, I'd rather see a lightweight module
system in 3.2 without namespaces or hierarchy get widely used first, and
then start to think about the full Module system a la 3.3a.

Avi