On Mon, Mar 31, 2014 at 2:21 AM, Balázs Kósi <rebmekop at gmail.com> wrote:


> self undeclare: aBinding key from: bindings
>
> makes the binding #Bar => Baz to become a binding pointing to nil, and
> when we get back to Environment>>renameClass:from:to:
> 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
>

Good catch Balázs, thanks!

I've committed a test and fix to trunk.

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.

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.

Colin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140331/d6f42461/attachment.htm