Hi Dan, 

I do not have the time to test anything right now for at least three weeks
but and maybe more.

> This is a great start on a module system for Squeak.  While it may not fill
> all the needs of commercial developers (support for cross-dialect development,
> etc), it does not preclude such tools, and...

The cross dialect development made by joseph was just blurring the picture
and just needed in case you want to produce a minimal image with only
compiler or even less. This has no impact on the system he developed

> it is small
> is is simple
The model of joseph was simple too: cluster package... the semantics model
could be certainly removed to base the computation of scope on the smalltalk
meta-model. 

> it is non-invasive ('weak' in Les's sense)
> it includes name spaces
> it addresses incremental updates

Does it support class extension?

> it provides for incremental refactoring from the community.

I have the impression that we will end up with a kind of competition between
something simple, nice,.... and a "big" stuff which is not the case. In fact
they will be no competition because joseph will simply throw away his stuff
and done.

 I hope sincerly that we will not lose the knowledge of a person like joseph
(even if he is a bit abrupt sometimes). This would be a pity. I'm not
underestimated the job of henrik, I'm just worried a bit that how can we
know if this stuff is the right way to go. You will say let us try.
But still my question remains. How can we collect the knowledge of people
like alan wirfs-brock or joseph to be sure that we are not repeating
something they already made 10 years ago and they know failed or does not
scale up.

My feeling is that I would like to have the advice of somebody like alan
wirfs-brock to give us some hints. At least I would like to know what issues
bring by the design of jospeh could be taken if you chose to go in that
direction. I think that not using the TeamV + Envy expertise of somebody
like joseph would be a pity. I think that this project is ___central____ for
the future of Squeak so I would really like that we do not jump on the first
thing that look right but really use the community to have ___the___ model.
For example, the errors defined, the package, cluster design was worth to
copy if needed. 

How are the namespace introduced?  at the level of the modules?
Because when I discussed with Alan Knight and Joseph at ESUG they said that
modules and namespace should be orthogonal.

You see the kind of question I have. When I see the namespace in visualworks
5 I think that this was too much for the gain because we still have to
register namespace to avoid clashes ;(

  
> Here are some experiments that I think would be fun to start on, even in this
> preliminary state (may require some further work on fileOut/In)...
> 
> Enhancing our tools to work with modules
> (Henrik has done a fair amount of this,
> but there is more to be done).
> 
> A good factoring of our monolithic image
> (again we have a start)
> 
> Make majorShrink (and other shrinks) work cleanly.
> I think of this as unloading weak modules.
> It will be an iterative process of refactoring,
> reducing dependencies, and rewriting majorShrink.
> In the end, majorShrink should simply be a series
> of unload commands.
> 
> A useful demo would be to have a couple of packages
> such as Connectors, ThingLab, or MathMorphs that
> could be loaded and run, and then unloaded.
> The demo would be to show that 'space left' was
> the same after as before.
> 
> Related to this would be the ability to unload
> various modules from our current image, and then
> reload them from their files, and have everything
> work again.  When this works everywhere, we will
> have accomplished the deconstruction of Squeak.
> 
> We can also now start to address modularity of
> projects, which could evolve into a component
> architecture for Squeak.
> 
> Thanks again, Henrik, for carrying this through to where it can be seriously
> evaluated.
> 
> - Dan