[Modules] finding the little buggers

Jan Bottorff janb at pmatrix.com
Thu Aug 16 22:17:58 UTC 2001


>What about using a test framework to decide if the class in question
>actually
>needs to be a diffrent version? If the package say it requires class
>String
>version 2.1 because it was developed on a system with String version
>2.1,
>but the calls it makes to String version 2.1 are the in previous and later
>versions of String, too.

My experience has been, developers track record on "backward compatible" 
new versions of modules is not so good. It seems like one goal of 
package/dependency management is to ASSURE a piece of code will be in a 
compatible environment. To me, this means the developer has tested the code 
with a specific permutation of updated external modules, and has nothing to 
do with the external module supplier assuring you "it's compatible". As the 
number of permutations grows rapidly with the number of modules, it seems 
like the farther you get from an exact tested module configuration, the 
greater the chance of flaws.

The Windows platform has had HORRENDOUS problems of run-time binding of 
modules. So much so, Windows XP will be supporting isolated environments, 
where your program can run with the EXACT version of modules it was 
designed/tested/released with.

For a while now, I've believed that dynamic code sharing at run-time is a 
terrible strategy. Code sharing at development time still seems like a good 
strategy. I suppose if the language has serious support to ASSURE the code 
you bind to at run-time was compatible with the code you tested against at 
development time, then things might work. The issue is figuring out who to 
point the finger at when the end system doesn't work. If you have a 
statically bound application, that doesn't depend on external modules, it's 
easy to know who is responsible. If your applications has modules from 20 
companies/people, all with the "latest" updates, it's anybody's guess where 
a problem is.

Actually, a Smalltalk image is a pretty good implementation of sharing at 
development time, and predictable versions at run-time.

- Jan






More information about the Squeak-dev mailing list