<br><br><div class="gmail_quote">On Fri, Jan 29, 2010 at 2:42 AM, keith <span dir="ltr"><<a href="mailto:keith_hodges@yahoo.co.uk">keith_hodges@yahoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
What is this scenario? Does it break the following load ordering?<br>
<br>
- add all new inst and class vars to existing classes (avoiding deleting any that need to be deleted until later)<br>
- add all new classes<br>
</blockquote>
<br></div>
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.<br>
<br>
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.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
- add all new methods<br>
- change all to be changed methods<br>
- delete all to be deleted methods<br>
- remove all inst and class vars from existing classes (deferred from step 1)<br>
</blockquote>
<br></div>
So basically your scheme is what the 1b loader is originally was designed to do.<br>
<br>
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.<br>
<br>
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.<br>
</blockquote><div> </div><div>Doesn't the FileContentsBrowser do this using PseudoClass etc?<br><br>Comment says:<br>I use PseudoClass, PseudoClassOrganizers, and PseudoMetaclass to model the class structure of the source file.<br>
<br>Karl<br><br><br></div></div>