Trygve Reenskaug <trygver at ifi.uio.no> wrote:
> 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.


That is a solution, but it seems hard to get there.  In addition to
needing the correct version of each *superclass*, any objects you use
need to be in classes that are versions you expect.  And what do you do
if you want an object with class version X, but you pass that object to
someone else who wants it with class version Y?  It seems that you need
to adjust the object's class to Y.  How can this be done?  It seems
doable, and extremely worthwhile, but it is difficult.

I suggest that we also pursue strategies that avoid needing arbitrary
package versions to interoperate.  A simple approach is to develop one
set of packages at a time and do whatever work is required to get them
compatible with each other.  With this approach, whenever an
inconsistency is discovered between these packages, we have the option
of solving it by declaring a rule one way or the other.  If some packages
are expecting 0-based indexing and others are expecting 1-based, then --
if nothing else suffices -- we can simply pick one way or the other, and
do the work to make the losing packages conform.  We can do these
things because of open source.

An extra benefit of this approach is that it can cope with any form of
inconsistency.  For example, we could insist that all method category
names are lowercased, or that all comments use British spellings.  This
suggests that, even if a good intermixing strategy is found for dealing
with many kinds of inconsistencies, we may want to continue following
the approach described above in order to handle the reamining forms of
inconsistency.


-Lex