[cut stuff]
Ok, let's see where this argument goes. Lets smack DMs and Modules together just as a thought experiment. This would mean (among other things) that a Module can contain it's own classes (just like now) and also classes which should be added to other Modules. Hmmm. Ok, so this would mean that each class must include information about in WHICH Module that class should be added, right?
And the same goes for each of the loose methods and the other "changes" that a DM can hold. Hmmm. To me it is quite plain datamodelling telling me that "Hey, wait a minute. Why don't I group these changes in ONE object that can contain the information of which other Module these changes are to be applied to?". And there you go - a DM.
OK, I think that I see some differences in that case between what Steph says and what you are saying: IF all classes/methods have to keep information about where they should be added, I think I agree. But, I don't quite agree that modules have to know WHERE it comes from and I do not want one module to change another module (data abstraction on modules). Modules can be applied on the system, but one module is not allowed to change a method/class/anything in another module. They are not even aware on each other in an explicit way.
Let's try to see how my arguments goes :-)
Suppose that a module contains 'definitions', in a declarative manner. Definitions about classes (to indicate what their subclass is from etc. - no definitions about their methods). Definitions about methods, that give the body of a method, its class and its category.
Some of this information can be partial: you can have a module 'Roel' that adds a method 'foo' on class 'Object'. This means that in order to be applied, Object has to exist. That is easy to check. If I understand it correctly, a DM 'RoelDM' should say that it is a DM for the existing Module 'SqueakSystem' (or something like that). This is something I do not like. This name should not be hardcoded: you can apply 'Roel' on anything as long as Object is there. And you can easily check this before.
Stef has this kind of setup in mind, and in that setup there is no difference between modules and delta-modules. A module is something which has definitions and which you can apply on a system. A check is done whether applications is possible before you really do so. This check merely needs to look whether all static references needed by the module are offered by the place where it is applied.
Note that we then started playing by adding namespaces and selector namespaces to this model. There we made some errors. People that are interested in this can just send a mail and we can send them the paper.
Another good point is this (and I might be on loose ground here because I am not totally sure how this works today):
Activation/deactivation is *per Module*. If all the DMs were contained inside the Module you wouldn't be able to deactivate those DMs separately!
So if Module AddressBook has two DMs - one for fixing some stuff in say one of the base Squeak Modules and another one for good coexistance with the Celeste Module (adding a menu choice in Celeste), what happens when I load and activate AddressBook but don't have Celeste? As I said, I am not sure how it works today, but it could activate the first DM and not the second (because Celeste isn't there).
Now - how would this work if the two DMs didn't exist and the "loose methods" were instead floating around inside the AddressBook Module? Suddenly you would also need to keep track of which of the stuff inside the Module that is activated...
The whole point of the DeltaModule is that it contains all changes
you
would like to do to *another* Module that is not yours in order to
make
*your* Module happy. So think of it as a ChangeSet with the
restriction
that it can only change *one* Module. And then add the very important aspect of reversability. A DeltaModule is activated and deactivated
when it is activated its changes are applied and when it is
deactivated
the changes are removed.
But the reversability is not based on the difference between deltaModules and modules. You could have the same with modules (merging deltaModules and modules). Reservibility is just there because of namespaces.
Eh. No. Ok. This is roughly how it works (today):
Modules are in fact never really "activated". They don't need to be because of what they are. They just contain classes which sits there in their own namespace.
When DeltaModules are activated - lets say one DM with a method removal in it - it actually removes the method in question from the class in that Module. But it keeps that CompiledMethod around in order to "hook it back in" when the DM is deactivated again.
So the deactivation mechanism has nothing to do with namespaces AFAICT
a DM must simply keep track of state in order to be able to do an "undo".
So again, what are the nice properties of this scheme?
- A Module is thus tremendously simple. It is just a bunch of
classes.
No history, no additions/removals or anything - it is very much
like a
category .st-fileout. It can't get simpler than that, and
simplicity is
our friend.
- A Module can't possibly conflict with another Module since it is
in
it's own namespace. This is a very important aspect. You can load
all
and any Modules into the image without any worry whatsoever, after
all
it's only classes and simply filing in classes never hurt anybody (unless the class initialization does dumb things, but that is
another
story).
This is important but just linked to the fact that you have namespaces.
No. I can't understand what it has to do with namespaces.
- As we all know somewhere the "dirty business" must be taken care
of,
otherwise all these Modules turn into isolated islands of no
connection
at all and just sits there like dumb ducks. :-) And this is the job
of
the DeltaModule. Think of it as a ChangeSet which can be reverted (activated/deactivated) and that can only affect ONE Module. Since DeltaModules carry all your changes in Modules that are not your own they by definition contain the areas of your code that CAN conflict
with
others.
So - the separation is very clear to me. When I write code
everything I
write can be separated into two groups:
- My own classes.
- Changes in other peoples classes.
Voila! Modules and DeltaModules. Since I control my own classes I
can
represent that code as a snapshot of the classes. But I don't
control
other peoples code so those changes are best represented as
*recorded
changes* to those classes.
What I want to say is that this is a code organization matter. You could do the same with one kind of module. Put your code into your modules and change to the system in other modules.
Hmm, can't see that. More on this below.
Ok, now if you do not like DeltaModules - what do you propose
instead?
You can't just say - just put it in the Modules, because then you
are
simply moving the problem into the currently nice, clean and simple Modules. And you can't just say "use ChangeSets" because they are
not
reversible and if I am not mistaken have other weird problems... The DeltaModules are meant to BE the ChangeSets of the future.
But changeset are not reversible because we do not add them a namespace. Imagine a changeset with a namespace, we could load it and unload it. Now we could also add variable initialization because we will need that. Then you can have class definition (including changes format), then you can have your own clean modules and deltaModules but without the need to have this separation.
Why would a namespace make a ChangeSet reversible? And what does it even "mean" to have a ChangeSet in a namespace? I don't understand that at all. AFAIK only globals are contained in namespaces - and concretely that means more or less classes and Modules.
Explain this to me. If a CS contains a removal of a method in class X and I load the CS, the method is removed, right? Now - what has a namespace got to do with undoing that removal?
Anyway continue your work on SqueakMap I thikn that this is important.
Thanks! I will. When I can stop answering all these posts on the list... The itch is unbearable!
I discussed with daniel at ESUG and he is right big bang changes do not work. So small increments are the way to go. I like the things he did for the dynamic menus and RB.
Me too. And generally I agree. I think Modules with namespaces may be an exception though... It is quite hard to "build incrementally" - some things need probably be done in big swoops. But that is just a guess.
He should also continue because this is important. If you can succeed to build a core of three or four people working together and trusting each other this would be great.
Just for your information. We were really working hard to produce the simplest modules system we could, since the modules discussion I have been reading everything that exist on modules, packages...
But for now I have the impression that we failed, Alex implemented several versions but our model has intrinsic problems and we could not find what we were looking for: asystem that let me play in my corner without impacting other but still been able to change other modules. I wrote a paper that I throw away.
Hmmm, tough!
We asked advices to some guys and were looking at SmallScript, old alen Wirfs-Brocks papers, other papers around. One of my dream would be to have a simple module system for language with extensions. but this is hard. You can discuss with Roel at OOPSLA (I will not attend because I have too much stuff to do).
Ok, I will talk with Roel.
So Henrik can say what he wants on me I do not care. We will see what we can do. I will not reply to other emails because I'm a trooooooolllllllllll
Please do reply. I don't think you are a troll and personally I think you both should "make peace" with each other. IMHO there is just too much waste of energy being upset over these things.
regards, Gˆran
Roel Wuyts Software Composition Group roel.wuyts@iam.unibe.ch University of Bern, Switzerland http://www.iam.unibe.ch/~wuyts/ Board Member of the European Smalltalk User Group: www.esug.org