Hi again!
I might have said the following things better in my other reply but anyway...
Stephane Ducasse ducasse@iam.unibe.ch wrote: [BIG SNIP]
It has two very nice consequences:
- 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"?
- 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:
- 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