[ENH][Modules] Delta Modules [was: Another version]

Les Tyrrell tyrrell at canis.uiuc.edu
Mon Oct 29 16:53:21 UTC 2001


----- Original Message -----
From: Edmund Ronald <eronald at rome.polytechnique.fr>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Monday, October 29, 2001 4:42 AM
Subject: Re: [ENH][Modules] Delta Modules [was: Another version]


> I seem to have forgotten to unsubscribe and this thread caught my eye. Oh
> well. As a journo, my heart goes out not to developers but to users. So:
>
> Among reasons for having modules two are obvious:
> + Facilitate  distribution:
>   Coders can release directly without reference to a central
>   distributing authority. Users can shop around for the pieces they
>   need.
>
> + Facilitate maintenance.
>   Coders can amend their code without referring to a central maintaining
>   authority. Users can upgrade modules incrementally during system life.
>
> In practice, the two conflict. Users get caught in DLL hell. Microsoft are
> not entirely dumb, but they realised it too late because it is a scale
> effect. The redhat people noticed the issues in upgrading Linux and tried
> to fix them with the rpm database. It sold the distro, but ultimately
> didn't work, just pushed back the problem by about 2 years, and then scale
> effects caught up again, as soon as the number of sources for things
> increased. Nowadays, with all these systems, people do a few
> customisations, then throw away the fragments and re-install a whole new
> boxful of toys again. The reason for the frequent release of complete
> Linux systems, when Unix is inherently modular, has become the
> certification by the vendor of coherent behavior of the whole.

Certification leads to a whole mess of issues, but one thing I thought would
be important ( years ago, before I realized it would be a Hard Problem ) would
be to come up with ways of decoupling inter-module dependencies... that is, I
didn't want modules to know about the specific existence of particualar other
modules, but they could be allowed to know what they *expected* about the
components in other modules- much like the way we do not require Classes to
know explicitly about which classes implement the methods they are sending,
but we do hold the *expectation* that the objects we are interacting with will
understand the messages we are sending them.

> I urge you, when analyzing this issue to look at the fundamental ways in
> which all known approaches have failed. Solving your module problem now
> for the existing handful of knowledgeable and sophisticated Squeak
> users/developers may not be the same as solving it for a distribution
> which has made it out of the lab into the wild.

This is why I really like the idea of supporting the ability to rapidly
develop, test, and dispose of various approaches to modularization- basically,
the "weak" modularity approach, where the existing tools remain unmodified
 ie, browsers and system dictionary are not changed ).  I've been plinking
away at Oasis for 5 years, and this has not been a straightforward process at
all.   Even now, though I believe that I really understand this problem a lot
better than I did back then, I am not ready to jump up and say "this right
here is absolutely IT- the Real McCoy, the Solution you've been looking for".

Fortunately, I'm no longer the only one ( or so it has seemed ) interested in
this.  There are some really good contributions coming out, and we can start
comparing notes.  These days I am building additional tools for Oasis ( a
message tracer, actually a subset of another already existing tool in Oasis ),
and looking at integrating ModSqueak, SCAN, and something of my own which is
intended to deal with the same problems that Collage should have been good for
solving.  I'm also looking at what it would take to get Oasis out of
VisualWorks- actually, there are big chunks of it that can be moved easily-
the only hard part is redoing the active components, not an issue if one
focuses initially only on inert components ( Oasis started out with
components, and I still have them ).   So, finally, after a really long time,
I am hoping to start sharing some of the stuff I've learned building Oasis
with the rest of the Squeak community.

- les






More information about the Squeak-dev mailing list