[Modules] finding the little buggers

David M. Siegel dsiegel at acm.org
Sun Aug 19 23:51:05 UTC 2001


At 06:03 PM 8/16/2001 -0700, you wrote:

>Alternately, you can separate the configuration information from the 
>modules.  So M1 and M2 would be defined as:
>         M1 (v1.5) = {requires M3 ...}
>         M2 (V9.8) = { requires M3  ...}
>
>and you would define a separate configuration specification:
>         M123-Config (3.2) = [M1 (v1.5) + M2 V(9.8)+ M3(2.7)]
>
>(Configurations can be modified, so they also need to be versioned)  When 
>M3 is revised you don't change M1&M2, you just create a new configuration 
>version:
>         M123-Config (3.3)  = [M1 (v1.5) + M2 V(9.8)+ M3(2.8)]
>
>The economies of scale become even most obvious when dealing with larger 
>numbers of modules.
>
>It's quite possible (and I would argue desirable) to design module 
>structure, version management, and configuration management in phases and 
>layers.  Start with a module specification that describe program 
>structure. (could be stored in a file or image or where ever). Upon that 
>layer a versioning scheme for identifying revisions of modules. (could be 
>encoded file names, or CVS, or a RDMS, in image, etc.Multiple alternatives 
>are fine).  Finally, add a configuration layer for making sure you are 
>using the correct versions.)
>
>Allen Wirfs-Brock

Aren't you assuming that module signatures are constant?

In actuality, new versions of Modules will include new selectors and new 
classes, and will remove
old selectors and old classes.

At the time I create a dependent module I know of at least one antecedent 
that worked -- the one
then present in my image.  This is valuable information that I want 
permanently associated with
my dependent module, not sitting in a configuration that could become 
detached and lost.

I'm inclined more towards having M1 (v1.5) require M3 (2.7) with the 
interpretation being any
version of M3 that is backward compatible with M3 (2.7).  The module system 
should have a
mechanism for stating backward compatibility, including a mechanism for 
_later_ asserting that
a module that was previously thought to be backward compatible has been 
discovered not
to be backward compatible.

-dms






More information about the Squeak-dev mailing list