[Modules] a summary of joseph's work

danielv at netvision.net.il danielv at netvision.net.il
Tue Sep 4 19:39:32 UTC 2001


As another Squeaker that was there -

I think the ModSqueak offers us a very powerful loading mechanism, and
we should take it.

It doesn't solve all the problems discussable under Modules, but I think
that's a good thing - we don't know what we want well enough on most of
those fronts. We know we want to be able to load and unload, and we
can't now, and ModSqueak will give us that. We know we want to have tiny
images, and ModSqueak (together with other tech, like ImageSegments or
whatever) will probably give us that in spades.

For the rest, I think what we really need is a higher stable starting
point for various explorations, and the ModSqueak work is engineered to
allow that.

You want to load two versions of a method at once and manage their
co-existance? ModSqueak won't do it, but it'll raise an exception when
the conflict occurs on loading, and you can catch it and play around.
You want to do Collage style overlaying depending on load order? same
exception, different catch. You want strict "that's MY method you can't
touch that" semantics - same thing.

Those sort of alternate policies would be hard to play with now, but
they'll be easy if we get ModSqueak.

Anyway, I think the real issue we should be thinking about is "Given a
good load mechanism, a clean (empty?) base SWT image, how does this
affect the way we work?"

* Are you going to start working daily in the SWT image? 
* and not use all the tools you're used to (Celeste, in my case) but
aren't part of SWT? 
	We might need to start separating those out into modules we can
maintain independent of the SqC image.
* and not see all the new cool eToy stuff SqC is working on?
* and anyway, if Lex and Daniel do start maintaining Celeste in a module
outside the SqC image, how does this mix in with the updates review
team? 
* how will I get the bug fixes and tweaks for Celeste, if that's not in
the update stream?

And so forth.

Ideas?

Stephane Ducasse <ducasse at iam.unibe.ch> wrote:
> Hi
> 
> I discussed and saw a lot of demoes of joseph's work at ESUG and I would
> like to summarize it.
> 
> Joseph's idea is to find a minimal structure that support the modularisation
> and on top of which other can build
> 
> - Based on a minimal semantic model: a layer on top of the smalltalk
> meta-model (implemented lazzily) that represents declaratively Smalltalk
> elements. Around 15 classes
> 
> - a Module/Cluster structure influenced by Team/V in which classes and
> classes extensions can go.
> 
> - a set of errors that can be captured to resolve differently conflicts:
> the base to build other tools such as Colleage.
> 
> - a modularizer: this class allows one to define the basic structure of the
> modules and automatically move classes in those modules. This is an
> extremely important aspect to let people explore different ways of
> organizing the code.
> 
> - The possibility to have envy like prerequisites validation or to let it
> lose so that we can hack fast something.
> 
> - a set of Browsers for the module ....: really cool to already have them!
> 
> I hope I did not forget anything.
> The point for me is that being able to compile Squeak from VA or VW is just
> a proof of concept that we could get a really small image, and even less
> minimal if we would stream in byte-code and remove the compiler ;)
> 
> 
> Stef 
> I hope this helps




More information about the Squeak-dev mailing list