Hi goran

Do not be mad (I know you can have some reason to be apparently I'm a 
trooooollllllll).
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 
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?

 >>>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.


 >>> 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.


 >>> 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.

 >>>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.



Anyway continue your work on SqueakMap I thikn that this is important.
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.
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.
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).

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

Stef





regards, Gˆran



On mercredi, octobre 16, 2002, at 09:35  pm, Göran Hultgren wrote:

> Hi all!
>
> Quoting Stephane Ducasse <ducasse at iam.unibe.ch>:
>>> 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.
>>
>> Clearly the way to go but still I do not understand why we need two
>> concepts.
>> henrik was fuzzy explaining that to us when he visited us too.
>
>> There is no comceptual different between a clean class def and a class
>> def plus a bunch of methods
>> sorry.
>
> But your statement is simply "wrong". A DeltaModule is NOT, and I 
> repeat - NOT -
> just a bunch of methods! A DeltaModule is LIKE A CHANGESET.
>
> It contains OPERATIONS like for example a method addition, a method 
> removal, an
> instvar addition, an instvar removal etc. etc. In short it contains 
> "changes"
> that can be applied (activated) and also reversed (deactivated). This 
> is very
> different from a SNAPSHOT of a class.
>
> Your statement can roughly be compared to the statement that "there is 
> no
> conceptual difference between an .st fileout of a class and 
> ChangeSet". And
> hopefully you agree with me that there is a difference there?!
>
> So in short - a Module contains a bunch of classes. Nothing more. A 
> DeltaModule
> contains your changes to classes in other Modules that you do not 
> control.
>
> Is there anyone else out there reading this thread that still do not 
> understand
> this? If there is, speak up because this is important. We are a 
> community and we
> decide where we want to go together.
>
> regards, Göran
>
> Göran Hultgren, goran.hultgren at bluefish.se
> GSM: +46 70 3933950, http://www.bluefish.se
> \"Department of Redundancy department.\" -- ThinkGeek
>
>
Dr. Stéphane DUCASSE (ducasse at 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