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


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