On Feb 22, 2005, at 7:53 PM, Dan Ingalls wrote:

> Meanwhile, I'd like to proceed simply to ask for people interested in 
> putting modules into Squeak.

Hi Dan,

Chalk me up as interested in modularizing Squeak, as designer, 
implementor and user.

One of the motivations for OmniBrowser was the observation that any 
modularization scheme would need tool support, and the current browser 
is an obstacle to that because it's difficult to modify. Indeed, the 
early versions of OB included package browsers based on PackageInfo 
packages, but I took those out on feedback from the community.

I agree with Florin that versioning is a key part of organizing 
Smalltalk code. One of my biggest frustrations with Monticello is that 
it's not been of any use to the Guides and Harvesters. That is, it's 
great for applications built on Squeak, but not so good for Squeak its 
self. I'm now working on a version of Monticello with a redesigned 
versioning engine, which I hope will be more useful in managing the 
kernel and core libraries of Squeak. More on this in another post.

I also implemented an experimental packaging system a few months ago, 
complete with an OB-based set of  browsers. It's not quite finished, 
and I'm not sure it's the way to go, but it's interesting nonetheless.

I quite like Alan Lovejoy's characterization of packages as units of 
separately deployable code, and I hope that doesn't get overlooked in 
the all the discussion of versioning, categories, namespaces, 
dependencies and so on. All those things are necessary to some degree, 
since they are ways of dealing with the additional complexity that a 
packaged image brings with it, but they're not end goals in themselves. 
Separately-deployable packages is what we're after.

Some more specific things I'd like to see.

- Decoupling the organization of the image (packages, environments or 
whatever) from the compiler's strategy for resolving names. This will 
make things like compiling in a sandbox, building small images, 
atomically loading packages and so on much easier.

- Good tool support for packages. Browsers, debuggers, changesorters, 
testrunners, etc should all be package-aware.

- Good tool support by packages. With a little care, we can make core 
execution machinery *much* easier to manipulate, and thus make it 
easier to write good tools. ClassBuilder is a good example: it is very 
difficult to deal with any other way than through the class definition 
doIts that appear in the browser.

- A fast-loading and compact format for distributing code.

Thanks for taking this on, Dan. I think it's really important.

Colin