Stephane Ducasse <ducasse at iam.unibe.ch> wrote:
> > There have been a several addons/fixes etc made by several people, but
> > we haven't integrated them yet AFAIK.
> > Alex did his stuff, Andreas, Daniel and more have done a lot too.
> > I still think that we can pull this off - we just need to "do it". The
> > problem has probably more to do with people trying to make money to pay
> > the rent etc.
> >
> >> Now the question how it is possible that 4 smart guys cannot 
> >> understand
> >> the modules system to the
> >> point that they can explain it. I think that this was the reason of 
> >> the
> >> failure of the modules.
> >
> > 1. No - I don't agree, Modules isn't that hard to understand. But you
> > need to TRY.
> 
> Sorry Goran. I do not want to be rude in public. But we tried and

No problem with rudeness - I admit to starting it with my post. ;-)

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

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

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

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

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

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

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.

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