Hi all!

"Andreas Raab" <Andreas.Raab at gmx.de> wrote:
> Hi Göran,
> 
> > > I have always liked (I still do) the general approach
> > > that Henrik took due to its nice algebraic properties 
> > 
> > That is nice to hear - then I am not alone in thinking that 
> > at least the ideas are "ok".
> 
> You might want to be careful about interpreting me that way. When I say
> I like the "algebraic properties" it does not automatically imply that I
> think they're a "good idea". Some of them I believe aren't. Or rather
> "aren't for people".

Ok.

>   "One must learn to distinguish between 
>    what is true and what is real"
>      - A. Einstein
> 
> Here is a simple one: Giving the module-hierarchy a "meaning" of any
> sorts. It's a perfectly fine thing to do in abstract algebraic
> environment but once it comes to modules and (more importantly) to how
> people _use_ them, it becomes very quickly clear that there's simply no
> unique meaning for a hierarchy. E.g., when you organize stuff
> hierarchically there's simply no unique scheme by which you go - I find
> myself using various models each of which depends on the concrete
> context I'm in. I thought about this for a long time (and had a couple
> of good discussions with Stephane about this point) since I used to
> think that a meaning in this hierarchy would be really valuable but in
> the end I decided that while it is "algebraically nice" it is still not
> a "good idea" for a module system to imply any meaning in hierarchies.

True - I have also read and thought about this and agree.
But one thing I am not totally clear on - what meaning does it have
today?
I have repeatedly said that downloading/loading/activation is done
"recursively" using the hierarchy but I am not so sure I am right in
this - I didn't have time yesterday to verify this (I was looking
through the latest 3.3a, reading comments etc).

Anyway, I agree and we should probably "fix" that. If there is any
meaning in there somewhere we should simply "remove it". :-)

> Similar for name spaces. From a more abstract point of view, it is
> perfectly legal (and very useful) to give each module its own name
> space. But when it comes to practical use ... uh ah ... Like Avi was
> saying, is this really the big problem? (or in other words: a "good
> idea"?!)

I have also for a long time considered Smalltalks "modelessness"
compared to Java's constant "import this, import that" a great
advantage. So I agree that it mustn't in practice become a burden. For
example, it could be nice if do-its and when I save code could "auto
expand" names like for example if I simply type "Morph" and there is
only one global named Morph in my image then it could autoexpand that
to, well whatever it should be. And if there were two or more to choose
from it could simply ask me which one I mean.

Things like this (including automatcally adding dependencies) would
perhaps be enough to maintain the "Smalltalk feeling".

> That said, I still think that parts of the design ideas are brilliant.
> Conceptually, I _love_ the idea of delta modules as being the "bridges"
> across different parts of the environment. Stephane has a valid point in

Me too.

> his argument about how to explain these but I believe that a lot of this
> can be hidden - e.g., does a user _ever_ have to see the deltas?! I
> would argue that he doesn't - from a UI point of view the system could
> handle the "delta separation" while giving you the view of that module
> as one homogenous entity. I claim that for 99% of all cases this is just
> what you need and then you get all the other nice properties from it for
> free

I agree and I also think that a bit of good explanations would go a long
way.
I maintain that it isn't THAT hard to understand. Most people can grasp
what a diff/patch file is and this is IMHO the exact same thing.

> (oh, and just by the way, I do _not_ like deltas for replacing
> change sets - they serve very different purposes in my understanding).

Well, yes for some things. If I understand this correctly (and mind that
this isn't implemented) the big differences are:

1. A DM only changes ONE single base Module. A ChangeSet can change
whatever it likes anywhere.
2. A DM must maintain state to be able to reverse itself
(uninstall/deactivate whatever you call it), a ChangeSet has none of
that.
3. A ChangeSet records operations (multiple sequential steps) while a DM
only describes one big step. In practive this means that a ChangeSet can
include 3 versions of the same method (because you changed it 3 times)
and when filed in only the last will be the one active. But a DM would
only contain the "last" method. In other words a ChangeSet is a
recording of changes in the order you made them creating an "editing
history". A DM is more like a ChangeSet with all unnecessary history
stripped away.

Again, this is my understanding of the concept DM - not the current
implementation (which is lacking a lot).
In short - a DM is like a patchfile to be applied to ONE Module.

So given this of course a ChangeSet is still useful as an instrument of
"history". But a DM could replace a ChangeSet when it comes to the role
of "deployment" when history is not interesting, instead you simply want
to move from point A to point B. If you understand what I mean. :-)

I should thus not have said that DMs will replace ChangeSets in general,
my fault. ChangeSets are still useful in many scenarios (but we should
fix those annoying problems with them like for example class
renaming...) but DMs would be more useful in packaging/deployment
(because of reversibility and being a Module with declared dependencies
etc)

> > > Also, there's this problem that at this point there
> > > is not a single concrete advantage for anyone actually
> > > using the module system - it's still in an abstract
> > > place in the future where "everything is going to get better" etc.
> > 
> > Yes, this is also the main reason IMHO that so few are trying
> > to push 3.3 ahead. As Avi wrote - (paraphrasing) if I can't work
> > *in* it then I won't work *on* it.
> > 
> > That is probably... THE biggest problem with 3.3 and Modules.
> 
> No, actually I don't think so. I think the biggest problem is complexity
> and backwards compatibility. There are not very many people who really

Well, ok. But the consequence of that is that noone can work in it and
thus it will not improve. :-)

> _need_ modules in a deep way (if there are more than ten people on this
> list I'd be surprised). Those who do have probably looked at the modules
> stuff. Let's take Avi (it would be worthwhile if you could say a few
> words about this yourself) and ask the question why exactly he hasn't
> done his work in the context of 3.3alpha?! For the things that I did,
> the answers are: #1 I need this with serious amounts of stuff working
> within 3.2 and porting (and while porting finding and fixing bugs in the
> module system) is not really an option. #2 It's been too hard to fit
> into specific places of the modules system because you got to understand
> too many of the details.

I read Avi's reply and I agree with this too. I have also stayed away
from 3.3.

> For a community effort it might just not be a good idea to concentrate
> that many responsibilities in a single place. I think it'd be relatively
> simple to handle all of the problems independently (e.g., source code
> access, class definitions, versioning, packaging, name spaces) and then,
> once the individual parts are there have a brainstorming session about
> who should use what in which context and how they all play together. At
> the very least people could try out individual stuff (which - as your
> and Avi's work show - is useful on its own) before they buy into the
> larger changes. Sure, it may not be as nice of an algebra, but I think
> it'd be much more "real". 
> 
> > But does this mean we should drop Modules(as in Henrik's code)?
> 
> I told you, don't expect any answers from me. I would find it a horrible
> waste of effort to dump all of it in particular considering the nice
> stuff that's in there. That said, I do believe that the only way to make
> this module system work is to have someone who deeply understands the
> overall design and is willing to "carve out" small enough tasks for
> collaborators which will in the end lead to a working overall system. I
> can't be that person (I simply don't have time for it) and Henrik
> doesn't either. Who else could and would?! And given that there's no
> benefit for anyone at this point the question needs to be asked if
> insisting on "fixing it" is helping at all, or if it isn't rather
> getting into the way.
> 
> Usually, I'd say "let's vote by feet" and bring in the alternatives and
> may the best code win. Unfortunately, it's not that simple with the
> modules since they are not easily "extracted" from the system (remember
> the "modularizing modules" thread?!) and the incompatibilities make it
> even harder.

I agree with everything you say here, given that the guru we need isn't
available - what do we do then?
I tried to describe a few ways of going forward in another post and I
think we should try to decide on a course.

Personally I haven't come to a conclusion - just looking through the
preambles of all those updates in 3.3 made my head spin and I started to
realize that "dumping" Modules isn't that easy either! I am not sure,
but currently I lean a bit towards at least trying to make 3.3a
"inhabitable" by throwing in all these extras we have - your MABrowser
for example, and see how far we can get.

When reading through the update-list I started to realize that 3.3 has a
lot of fixes/features already to offer compared to 3.2 so perhaps if we
just make it at least "possible" to work there then that might be a good
start.

regards, Göran