There has been many suggestions about how a package can survive a change in 
its class library. I believe the only workable solution is to let a package 
include all required objects and ignore any new versions that may come along.

Example 1: In a very early version of Tektronix Smalltalk, we compensated a 
off-by-one error in a library class by adding 1 in the subclass. We then 
got a new and corrected version of the library. Out application was again 
off-by-one...

Example 2: A program working with bitmapped graphics worked perfectly until 
we got a new version of the VW class library. Our response time then went 
up from milliseconds to hours. There were no interface changes, but a 
library class that formerly cashed a transformed bitmap now computed it 
afresh at every request. Cashing it outside the inner loop in the app 
method got us back to millisecond response time.

Example 3: "On June 4, 1996 an unmanned Ariane 5 rocket launched by the 
European Space Agency exploded just forty seconds after its lift-off[...]It 
turned out that the cause of the failure was a software error in the 
inertial reference system. Specifically a 64 bit floating point number 
relating to the horizontal velocity of the rocket with respect to the 
platform was converted to a 16 bit signed integer. The number was larger 
than 32,767, the largest integer storeable in a 16 bit signed integer, and 
thus the conversion failed."  Here it was the same program using the same 
library, it was merely a faster rocket.

The surface area between a system of classes and their superclasses is 
enormous, there is no way the library developer can foresee the effect of a 
change on the many and unknown users of the library. My own experience is 
also that it is practically impossible for an application developer to see 
the effect of hundreds of changes in the library even if they are carefully 
listed (as PPS used to do).

The solution I dream about for BabyUML is that it shall support many 
versions of a class simultaneously. Library classes shall not be known by 
name, but by object ID. The loading of a package should automatically cause 
the loading of the objects it requires if they are not in the image 
already. Object IDs must be unique in time and space. I estimate 90 bits, 
but local aliasing should be possible for efficiency. It seems sensible to 
use a finer granularity than class objects, "Traits" looks very promising 
in this context.

Finally, testing can only show the presence of bugs and not the absence of 
bugs. Bug free software takes bug free design and bug free implementation. 
The purpose of testing should only be to confirm that everything is OK. But 
our present programming paradigms do not yield readable programs. The goal 
of the BabyUML project is to make it practicable to create simple solutions 
to complex problems.

Cheers
--Trygve





-- 

Trygve Reenskaug      mailto: trygver <at> ifi.uio.no
Morgedalsvn. 5A       http://heim.ifi.uio.no/~trygver
N-0378 Oslo           Tel: (+47) 22 49 57 27
Norway