<br><br><div class="gmail_quote">On Thu, Jan 28, 2010 at 5:42 PM, 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="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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.</blockquote><div><br></div><div>That's broken. It should compute the correct definition and not catch compilation errors. A loader that hopes is hopeless ;)</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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></blockquote>
<div><br></div><div>I know it's painful but good tests here are hugely valuable (albeit rather tedious to write).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<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><br></div><div>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.</div><div><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font color="#888888">
<br>
Keith<br>
<br>
</font></blockquote></div><br>