how this is possible that I cannot explain the modules system in 5 sentences. Or may be alex, roel, nathanael, andrew and I are just stupid. May be.
Nope, you most definitely are not. But I still don't really see what it is that is so hard. Obviously I have misunderstood it all.
We can understand any hard stuff without problem but why the model is not that simple that I even have to think about it. That's the real point why modules and deltamodules....
I don't claim to understand all of it in depth but at least enough to grasp it. I mean, hey - essentially (cutting away some small details): a) a Module is a bunch of classes (globals) and you need to explicitly "import" the other Modules that you use in your Module. Very similar to import/include in all the {}-languages. b) The Modules are arranged in a global namespace hierarchy. Very similar to Java. c) The only thing remotely hard to understand here is IMHO DeltaModules and they are more or less like a ChangeSet that *only* affects one given Module. Another way of saying this is that a DeltaModule D specifies the difference (like a patch-file) that needs to be applied to a Module A version 1.0 to turn it into version 1.1.
I do not like this idea of difference but this is my problem.
Well, liking is one thing. But do you understand it? I must say I found it pretty neat.
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
- 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. \
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
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!
If anything I write is wrong - correct me. I don't have these things fresh in my head since I too have not been in 3.3-land for quite some time... :-)
Me too
Ok, what was hard about this? Yes, I am being a bit pushy here because all this talk about Modules being so hard is getting on my nerves. Don't feel offended - nothing personal.
- Modules has NOT failed. It's in 3.3 *alpha* which means that it
isn't ready for use yet. We just need to finish it.
So I'm waiting to see it failed. Let say it like that. Have you see how many changes made by the community have been harvested recently. How many people are using 3.3a. Not that much.
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.
In fact almost all community efforts in Squeak have been down and I don't think it has much to do with technical reasons - it has to do with the IT-industry.
not only
If you just take a look at the code Henrik wrote and which especially Daniel and Andreas (if I am not mistaken) has hacked a bit further on - you will see that a lot of it works very good.
I'm seeing that the code is bad. I'm saying that the model is complex.
It the code really "bad"? I didn't think so, of course code can always be improved but I didn't think it was "bad". And yes - the model is complex - but is it *unnecessarily* complex? I am not so sure.
because what is needed is a concept for grouping and manipulating class definition and method definition. I discussed with daniel at ESUG and he told me that now he understand the idea behind Ginsu. The model was small and simple. But joseph succeeded to pissed of everybody so this is great.
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.
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.
For example - the ability to have classes loaded in the image (fully compiled etc so that tools work and so on) but not having them activated in the name space seemed like a brilliant approach. And activation through a big become-operation seemed very neat.
Indeed
I talked with Henrik about Ginsu and he said that he had looked at it and thought that similar goals could be achieved better using other techniques. And then he wrote Modules. Since he knows this stuff infinitely better than me (especially compared with Ginsu) I can only hope he posts his thoughts.
So cool we are living in a happy world. I looked at the code of henrik. Alex too. Believe me.
I believe you. And sorry for my tone in the last post - I was a bit... wound up. ;-)
regards, Gˆran
Dr. Stéphane DUCASSE (ducasse@iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes