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.


> Keith
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100129/60c0d794/attachment.htm