[squeak-dev] Re: [Cuis] Cuis - Cross fork compatibility of
packages: A proposal
siguctua at gmail.com
Fri Jan 29 20:26:13 UTC 2010
On 29 January 2010 19:05, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> On Thu, Jan 28, 2010 at 5:42 PM, keith <keith_hodges at yahoo.co.uk> wrote:
>>> 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.
> That's broken. It should compute the correct definition and not catch
> compilation errors. A loader that hopes is hopeless ;)
>>> - 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.
> I know it's painful but good tests here are hugely valuable (albeit rather
> tedious to write).
>> 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
> I don't think so. What is useful is a well-defined readable implementation
> of the above load order. Bells and whistles and convoluted code are what's
> _not_ needed.
The loading logic should be clearly defined and straightforward.
Igor Stasenko AKA sig.
More information about the Squeak-dev