Hi again!

I might have said the following things better in my other reply but
anyway...

Stephane Ducasse <ducasse at iam.unibe.ch> wrote:
[BIG SNIP]
> > It has two very nice consequences:
> > 1. Modules (regular ones) could then simply be a bunch of classes.
> > Period.
> But modules could be a bunch of classes and method definitions. Period
> 
> No need of deltamodules that have to be located under 
> module...blblbalbalbablabl

What do you mean "no need"? 

> 
> > 2. Any "changes" needed in other code to make a Module happy where
> > collected in the DeltaModules. This meant that the DeltaModules carried
> > all the "dirty tricks" and made them visible and concrete. This is a
> > good thing.
> >
> > And finally, since a DeltaModule essentially is the a "cleaned up"
> > version of ChangeSet we could use it for those purposes too. Remember
> > that a DeltaModule is reversible - this is a very important thing to
> > have. According to Henrik (I haven't looked at them much) ChangeSets 
> > are
> > pretty weird beasts...
> 
> But may be we should simply throw away changeset or used them as a 
> storage mechanism.

Yes! The idea is to throw away ChangeSets and replace them with
DeltaModules which are more or less the same thing but better.

> > Sidenote: Just look at SqueakMap for 3.2. We now have single-click
> > installation of .cs files working fine. But deinstallation will of
> > course never work since ChangeSets are not reversible.
> 
> I would loved but a book is grilling and a smalltalk lectures (lucky me)
> fall literally on me, so please show it to roel at OOPSLA

Sure.

> >
> >> I do not like deltamodules. Then the hierarchical view of modules is
> >> just about
> >> names reservation and this is mixed with modules structure here.
> >
> > AFAIK the hierarchy (currently) has two purposes:
> > 1. A hierachical naming space makes finding stuff easier. Nothing
> > technical about that - it's just nice to have it hierarchical.
> > 2. Since we then suddenly have a hierarchy we can choose some meaning 
> > to
> > attach to the child-relation (or we could choose not to - but why 
> > not?).
> > IIRC some operations work on a Module recursively.
> > Loading/unloading/activation/deactivation to be precise. But apart from
> > that I don't think the child-relation has any other "role" in Modules.
> >
> > Personally I think we could perhaps let the operations mentioned
> > (loading/unloading/activation/deactivation) instead work only through
> > the dependency graph and simply ignoring the child-parent hierarchy. I
> > think Stephen Pair has made that proposal earlier. This would leave the
> > hierarchy as being only for naming.
> 
> I agree I think that naming should not be mixed with childparent. What 
> a mess!

Well, I need to look into this more closely before saying anything else.
And ask Henrik. :-)
There probably are more thoughts here than meets the eye. But
instinctively I think Stephen might be right.

[SNIP]
> > I would say that harvesting has been down for *both* 3.2 and 3.3 - that
> > has nothing to do with Modules.
> 
> Yes it has because as an harvester I do not know how to proceed.

Well, ok. That is of course bad. Personally I haven't done any
harvesting yet and - yes - I am immensely ashamed of that, but I think
that my work with SqueakMap is a good excuse. ;-)

If you don't know how to harvest for 3.3 then that is definitely a
problem. But I though that we still use ChangeSets in an updatestream
just like 3.2...

[SNIP]
> > I am not so sure - Ginsu is a model describing Smalltalk source code -
> > separately from the Smalltalk model itself. At least that is my
> > understanding.
> 
> But we could have retrofitted in Squeak. The separation was not the key 
> point.
> The key point was that we could manipulate code such a global Variable 
> definition.

If I am not mistaken we can do that in Modules too.

> > Modules is instead an extension to the Smalltalk model of
> > classes. Way back when I talked with Henrik about this I found his
> > arguments and model much more appealing than having an "extra" model
> > like Ginsu.
> 
> Henrik could find convincing arguments but now what do we need: a good 
> packaging mechanism
> and a simple one.

I still think Modules is good and simple. We just need good tools! And
of course finishing the job.
I intend to start digging in as soon as SqueakMap is up and running in
3.2. And in fact - SqueakMap is one of the puzzelpieces missing from
Modules - it works as the top level "DNS" for resolving Module names
into repository urls. So... actually, I have been working on finishing
up Modules!

Have you seen Andreas browser?
It has a notion of "current Module" and whenever you change another
Module it automatically creates DeltaModules for you in the correct way.
You can go by your daily coding business just like before.

regards, Göran