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
>> loader.
>
> 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.

+1.

The loading logic should be clearly defined and straightforward.

>>
>> Keith
>>
>
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.