Given the class RenameTest with the following methods:
myOwnClass
^RenameTest
RenameTest
^self class
test
^self RenameTest
If you rename the class RenameTest to NewName, the method myOwnClass fails compile, since the older class name isn't there (dialog needs some work, too).
Somehow, it cancels the rename and you can edit your method so it will recompile (say, add # to the className so it's a symbol), and a subsequent rename will succeed, and you can edit that method again to refer to the new class by name.
(note that my image got into a state where the second rename was throwing some ugly errors, but it cleared up and does not reproduce).
This issue to make rename work in this scenario; that is not required for first release.
More testing would be nice, to see if the ugly dialogs can be reproduced. I think I'd earlier done an abort after a rename, but that didn't help reproduce it.
Given the class RenameTest with the following methods:
myOwnClass ^RenameTest RenameTest ^self class test ^self RenameTest
If you rename the class RenameTest to NewName, the method myOwnClass fails compile, since the older class name isn't there (dialog needs some work, too). Somehow, it cancels the rename and you can edit your method so it will recompile (say, add # to the className so it's a symbol), and a subsequent rename will succeed, and you can edit that method again to refer to the new class by name.
(note that my image got into a state where the second rename was throwing some ugly errors, but it cleared up and does not reproduce).
This issue to make rename work in this scenario; that is not required for first release.
More testing would be nice, to see if the ugly dialogs can be reproduced. I think I'd earlier done an abort after a rename, but that didn't help reproduce it.