[squeak-dev] Re: [Cuis] Cuis - Cross fork compatibility of packages: A proposal

keith keith_hodges at yahoo.co.uk
Fri Jan 29 01:42:44 UTC 2010


> What is this scenario?  Does it break the following load ordering?
>
> - add all new inst and class vars to existing classes (avoiding  
> deleting any that need to be deleted until later)
> - add all new classes

The original innovation of the 1b Loader was to begin by defining  
classes using a union of the old and new instVars list , in an attempt  
to keep as much working as possible. So yes that implements your  
suggestion above.

The old loader would just load the new class definition, and if that  
compilation failed, try again later in the hope that any failing  
methods were removed in the remove method step.

> - add all new methods
> - change all to be changed methods
> - delete all to be deleted methods
> - remove all inst and class vars from existing classes (deferred  
> from step 1)

So basically your scheme is what the 1b loader is originally was  
designed to do.

However it looks like an extra "remove method" step has crept in at  
some later point in time, probably to fix one of the other conflicting  
bug scenarios, and this is what is causing the problem.

What would have been most useful, (and I didn't know how to achieve  
this) would be a simple hook to enable new method to be compiled  
against the fictional not yet installed future class definition, but  
then installed in the old class, just before committing the new class  
definition. This would not be full atomic loading, but it would yield  
a much less quirky standard loader.

Keith



More information about the Squeak-dev mailing list