Squeak Starter

goran.hultgren at bluefish.se goran.hultgren at bluefish.se
Thu Oct 17 10:08:07 UTC 2002


Stephane Ducasse <ducasse at iam.unibe.ch> wrote:
> Hi goran
> 
> Do not be mad (I know you can have some reason to be apparently I'm a 
> trooooollllllll).

:-) I am not mad! Henrik might be but I am not.

> I just do not have the time to reply. I have to finish a complete 
> lecture on OOP for Monday
> and a kid at hospital (great birthday). What I just want to say is that 

Hope he/she gets better. There *are* things much more important than
modules in Squeak...

> if modules are
> similar to changeset (i.e., contains method removal, addition, class 
> changes),  I do not
> see the point to have deltamodule and modules, we could only have 
> modules = changeset + namespaces.
> Having a clean module with no class extensions is cool but why this is 
> different than a module with?

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.

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?
> 
>  >>> 1. 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.
> 
>  >>> 2. 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.

> 
>  >>> 3. 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:
>  >>> 1. My own classes.
>  >>> 2. 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



More information about the Squeak-dev mailing list