A bunch of observations

[goran.krampe at bluefish.se]

Hi all!

I just (phew) read most of the "Modules" thread and took some notes that
I would like to share with you. I am trying to be brief.

First of all - some of the most profound postings came (not
unexpectedly) from Colin, I think we all should read them one more time,
this is the first one:

	http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-February/08
9005.html			

	The most important points here IMHO:
	- Colin supports Alan Lovejoys definition of "separately deployable
code" (well, not "objects" perhaps). I do too. We should "choose" what a
"module" is, and that is IMHO the overshadowingly most important
attribute of it. Though "objects" is a better word than "code".
	- The decoupling of name resolving. This one is a no-brainer, we should
just factor that out, regardless of how we intend to actually make it
work.

..and then this one which is *very important* I think:

	http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-February/08
9304.html

	- Here Colin captures very nicely a way to partition these matters.
Agree?

Now in random order:

1. Resolving names. A recent post pointing at how Forth does this
reinforced the idea that unbound references (typically names of classes)
should be resolved and bound at "load time" and then after that "be what
they are". Again this is my perception, may be wrong. Colin is also
leaning in that direction AFIACT, and instinctively I would agree. :)

Note: In my namespace work I have always considered that resolving a
name like HTML::Parser (or whatever) can be done using various
techniques and mappings. Even if it is an absolute name (a
prefix/namespace and a name in that space) there is nothing stopping the
resolver to for example map to another namespace or whatever. It is only
helpful that it doesn't "just" say Parser.

2. Dan talked about having a module hanging by a single reference and
thus be ImageSegment-friendly and also be "user friendly" by saying that
you have the module as long as it is "there". We could typically just
have a Collection somewhere with the Module instances in it - and if you
remove one, it is thus "uninstalled". I agree, it would be a *very* nice
model - *if* we can pull it off. :) It reminded me of Gobo-Linux
(http://www.gobolinux.org) - a new Linux distro which actually tries a
similar thing, each installed piece of software lives in a single
directory on disk. An uninstall is simply done by removing the directory
(I think).

3. Colin and the others are working hard on MC2 etc and I just want to
give a hint on something extraordinarily cool in that arena. Darcs
(http://www.darcs.net). Darcs is a new distributed version control tool
that has something that AFAIK no other tool has - a "Theory of Patches".
The net result is remarkable smartness, bordering on magic. :) Slate
just moved over to using Darcs and even though I have no current use of
it, it is my preferred choice today over all the others (Arch, Svn,
yaddayadda). Perhaps a few things in there to sneak a peek at? Perhaps
Colin already has. :)

4. And finally a general observation - "Isolation considered harmful?".
Many of the ideas and concepts in this area (modules, namespaces,
versioning etc) are about further isolating things from each other - in
the belief that more isolation improves stability and is only a good
thing. Sure, it sounds reasonable on first sight - if you have very few
dependencies, then the risk of breaking when the world around you
changes is less. But... it also means that things that *should* be
coupled are instead duplicated and forked off. One example is
namespaces. People often advocate a total isolation approach - each
developer gets his/her own little sandbox, and we all live happily ever
after, right? Wrong IMHO. This is what I call "pessimistic" namespaces.
If each of us are isolated from the rest, then we are bound to
reimplement things over and over - a dozen SocketStream classes,
multiple SMTPClients etc etc. So isolation is NOT only a good thing - we
need to have processes that enable us to discover things - like for
example "discover" that there already is an SMTPClient class and prevent
us from making our own, and also encourage us to improve on the one that
already exists.

regards, Göran