It could fail. It also collected runtime information to improve correctness. See: https://www.researchgate.net/publication/220346807_A_Refactoring_Tool_for_Smal

It could fail. It also collected runtime information to improve correctness. See: https://www.researchgate.net/publication/220346807_A_Refactoring_Tool_for_Smalltalk https://www.researchgate.net/publication/220346807_A_Refacto... E.g.: “In a reflective environment such as Smalltalk, any change to the system can be detected by the system. Therefore, it is possible to write programs that depend on the objects being a particular size, or that call methods by getting a string from the user and calling perform: with it. Therefore, it is impossible to have totally correct, nontrivial refactorings. However, the refactorings in our system handle most Smalltalk programs, but if a system uses reflective techniques, the refactorings will be incorrect.” “To correctly rename a method, all calls to that method must be renamed. This is difficult in an environment that uses polymorphism to the extent that Smalltalk does. Smalltalk also allows dynamically created messages to be sent via the perform: message. If an application uses this approach, any automatic renaming process has the potential of failure. Under these conditions, guaranteeing the safety of a rename is impossible. “The Refactoring Browser uses method wrappers to collect runtime information. […] Whenever a call to the old method is detected, the method wrapper suspends execution of the program, goes up the call stack to the sender and changes the source code to refer to the new, renamed method. Therefore, as the program is exercised, it converges towards a correctly refactored program. […] The major drawback to this style of refactoring is that the analysis is only as good as your test suite. If there are pieces of code that are not executed, they will never be analyzed, and the refactoring will not be completed for that particular section of code.”