<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 31, 2014 at 2:21 AM, Balázs Kósi <span dir="ltr"><<a href="mailto:rebmekop@gmail.com" target="_blank">rebmekop@gmail.com</a>></span> wrote:<br>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div></div><div class="">self undeclare: aBinding key from: bindings<br><br></div>
makes the binding #Bar => Baz to become a binding pointing to nil, and when we get back to Environment>>renameClass:from:to:<br></div>it uses that same binding object and just changes the binding key to the new name, so at the end we have a binding #Baz => nil<br>
</div></div></blockquote><div><br></div><div>Good catch Balázs, thanks!</div><div><br></div><div>I've committed a test and fix to trunk. </div><div><br></div><div>The fix is to create an entirely new binding for the new name, rather than reusing the old binding and just chaining the key. That's a change in behaviour, but I think it's correct. That way methods that refer to the old name will now have an undeclared binding with a nil value, and the new name will correctly refer to the renamed class. </div>
<div><br></div><div>This avoids leaving methods in an inconsistent state where their source code doesn't match their compiled state. Methods that refer to the old name will have an undefined binding, while methods that refer to the new name will be bound to the correct class. That's how it should work at the low level—the tools should be responsible for fixing up the source code to use the new name and recompiling.</div>
<div><br></div><div>Colin</div></div></div></div>