Dan Ingalls wrote:

> What does this say about our architecture for modules?  To me it says that
> what we want to start with in the image is really just the support necessary
> to receive a new module.  This looks like a fairly small requirement -- it
> could be satisfied by a combination of Lex's ChangeSet proposal and the
> existing Environments work, with some cleanups and simplifications.  I'm
> curious if people generally agree about this and, if so, if it would be worth
> summarizing this requirement as a sub-project of the overall effort.
> 
> A parallel sub-project would be to extend our tools to work with this new
> architecture.
> 
> This would seem to be the first step to shoot for, because it would enable...
> 
> 1.  A refactoring of the entire system
> along the lines above
> 
> 2.  More reliable and consistent sharing
> of major projects in the community
> 
> 3.  A target image specification for the
> more serious team development tools
> which could themselves be added as modules.
> 
> Do people think this is a reasonable first step?
> 
> Does anyone want to propose a spec for what needs to be done?
> 

Dan,

Here is the latest installment of the "modularity of modularity" series. I
think that right now we don't really need to work out how the system should
be partitioned. If we just put a basic modularity system in place, then when
it is in place we can beginto work on the breakdown of the system, to refine
and change it into more appropriate pieces.

As the basis for structuring all the code within the image, I think
Environments will serve our efforts well. The foundation looks quite solid
enough to build on. It is also complementary to the ModSqueak work (which
seems to just plug into a namespaces facility) and other code
loading/management, version management solutions, and so on that may happen.
Moreover, E:s make up the "innermost" piece that will underly everything
else that we will need to add.

Also, I've seen no proposal that is strongly different from it. Rather,
everything that's come up can be introduced by more or less incremental
changes to the existing Environments scheme. For example, even something as
fundamental as to use a different kind of module composition scheme.

Therefore I had the following idea. Why don't we sooner rather than later
let Environments "go live", ie. put it into use by making the test pilot
image operate under the Environments scheme.

(In effect we would put Environment reorganizeEverything in a change set
postscript, but also provide ready-made images).

The reason is that while E:s are quite good already, we need to make it more
stable, and up to the task so to speak. And this won't happen as long as it
sits as stale code. It seems that not many Squeakers have looked at the
Environments code. It has been in the standard image for 1.5 years, and
nothing has happened!

Since it will be "test pilot mode", some initial instability should be
acceptable, and people have a choice of staying with the latest final
version.

And whenever we would choose to make such a radical change, it would have to
be a bumpy ride for a while anyway. And unless people start using it for
whatever they normally do, it will never become usable. It is the classic
problem of bootstrapping, chicken or egg, etc.

By making this change, people will start using it, and only then will tool
improvements, bug fixes, etc. start to come, and only in that way will it
become usable. In the short time I've used it, I've already fixed one
current showstopper in this way (exceptions crash the image hard), and made
one semantic change (don't look for globals in the environments of
superclasses). 

Over time, change sets will come in to 1) fix bugs 2) add features 3) even
improve the semantics 4) refactor existing code by using the new system
(this was your original topic). All these things can be done incrementally.

Thinking about it, I can't think of any other way of doing it that would
work. It won't happen that we'll be able to release a full, perfect solution
at once. It needs to be worked out over time.

Now a suggested concrete plan of action:

There are a few things that I think need to be changed in the current E:s
scheme, for instance we need a stronger scheme for module composition than
single inheritance (I've outlined most of that in an earlier mail).

In a day or two I'll post a proposal for a very simple substrate for module
composition that also includes a basis for dependency management. I have
looked rather closely at the ModSqueak code as well.

We might want to put changes such as those in place before making the
switch. We'll have to decide on a scheme first of course. But we don't even
need to do that before making the switch, eg. if there is no consensus.

Also, a few of us might want to start ahead before then, to weed out the
worst problems. 

Lastly, we might want to finalize 3.1 before the switch (soon) and let this
change happen in early 3.2 alpha. (I don't think this version change is
absolutely necessary, but others may.) It seems suitable that the current
round of update collection, started by Stefan (sma) and others, is finished
before 3.1 is finalized.

Henrik