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

karl ramberg karlramberg at gmail.com
Fri Jan 29 21:16:23 UTC 2010


On Fri, Jan 29, 2010 at 2:42 AM, 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.
>
>
>  - 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.
>

Doesn't the FileContentsBrowser do this using PseudoClass etc?

Comment says:
I use PseudoClass, PseudoClassOrganizers, and PseudoMetaclass to model the
class structure of the source file.

Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100129/d622affc/attachment.htm


More information about the Squeak-dev mailing list