Modules (was Re: Squeak Starter)

Göran Hultgren goran.hultgren at bluefish.se
Wed Oct 16 20:52:03 UTC 2002


Hi all!

Quoting Avi Bryant <avi at beta4.com>:
> On Wed, 16 Oct 2002, [ISO-8859-1] Göran 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
> gross
> > factual errors? Daniel, what do you think?
> >
> > I continue to stand by the Modules codebase as a good start, but I am
> always
> > 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

Yes, good point.

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

Since 3.2 will be the stable release for quite some time this is good to hear. I
still have to look into DVS. 

A sidenote: One reason for the Modules work being so... uncoordinated is the
lack of a good "CM" tool like CVS or similar. Would you say (I trust your word)
that DVS is the best thing going in this respect for Squeak currently? If that
is the case, then perhaps we should consider using it for all the
Modules-related cooperative work that needs to be done in 3.3. Currently there
are a whole slew of .cses floating around that needs to be integrated etc. The
lack of something CVS-ish (and I am talking about the very simple
update/commit-cycle) is IMHO a big hurdle for real cooperative development in
the Squeak image and the Modules area is a good example where we really need this.

Even more on the side:
Of course what I REALLY would want is an interactive update/resolve
conflicts/commit-cycle using DeltaModules in 3.3 thus creating the
CVS-optimistic-concurrency model of development with intelligent conflict
resolution tools instead of simple "oops, those lines are too close"-logic.
And then coupled with a bit of realtime feedback inside the browsers on who is
doing what and where and you have my wet dream of a CM system...

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

True but I have steered away from that since I didn't want to duplicate efforts
- Modules already has functionality for it.

It would be a pity if people started to "rebuild" stuff (that is already
implemented partly in 3.3 Modules) in 3.2 instead of helping out and finishing
the job in 3.3... 

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

I agree but if you have read the Swiki pages about Modules you realize that
there are a lot of cool stuff there. The ability to separate loading from
activation, working on different versions of classes/modules, clean atomic
stages of downloading all dependencies, loading them all into the image and
finally activating it all, the global namespace and so on.

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

Perhaps the combination of SqueakMap (soon coming in 3.2 updates) and DVS would
work as a good lightweight solution for 3.2. But I still think we should push
ahead on 3.3 Modules.

Oh yeah, forgot to add my list. One thing off the top of my head though: Image
building instead of image stripping. That is a biggie in my book.

regards, Göran

Göran Hultgren, goran.hultgren at bluefish.se
GSM: +46 70 3933950, http://www.bluefish.se
\"Department of Redundancy department.\" -- ThinkGeek



More information about the Squeak-dev mailing list