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

Stephen Pair spair at advantive.com
Tue Oct 23 17:56:20 UTC 2001


I just want to jump in with a couple of thoughts on Henrik's module
system.

It took me a while to understand why Henrik insisted that loose methods
should be separated into these delta modules.  I had to hear him talk
about it a few times at OOPSLA to get it.

There are really two competing concerns w.r.t. to loose methods that are
at work here:

1) You want to be able to sling code at the speed of thought, changing
anything and everything, then be able to dump that work out of an image
and load it into another image and have it automatically pull in module
dependencies and not break other things in the target image

2) You want to maintain a coherent modular decomposition of the system

Allowing loose methods to exist separate from their associated class
would achieve the first objective, but not the second.  I can see now
that if loose methods were allowed to exist in modules, the modular
decomposition of the system would quickly become a tangled, unworkable
mess.

On the other hand, keeping these things in delta modules accomplishes
the first objective, while keeping those loose methods defined as
enhancements on another module.  It's then easier  adapt your module to
a new situation because you only need to create new supporting delta
modules, rather than create a new version of your base module.  SUnit,
with it's dialect specific pre-load change set, is a good example of
this.  (SUnit uses some funny method names (like #sunitEnsure:) to
implement a poor mans selector namespaces, but that's another story)

Regarding the distinction of delta-modules and non-delta-modules, I
think this will eventually need some refinement.  Really, all modules
should be delta-modules.  A regular module is just a delta between
nothing and something.  The real question is: what is the basis for the
deltas?  If you think of a module "A" with three versions (1, 2 and 3),
the evolution of this package looks like:

A.v1 -> A.v2 -> A.v3

These three versions repesent a snapshot in time of the state of this
module.  The states in between these three versions are (for whatever
reason) not important enough to capture.  The question is: how to I
arrive at the v3 state?  I could load three delta modules that take me
sequentially through each state to arrive at v3, or I could load one
delta module that takes me all the way to v3.

- Stephen






More information about the Squeak-dev mailing list