PackageDescription: RBDynamicRefactorings


RB Dynamic Refactorings

Last published: October 21, 2009 by 'nross'

Defines 4 Classes
Extends 5 Classes

This package was created in the Custom Refactoring project from John Brant's code for dynamic refactorings. The project extended the UI and the test suite; the core is relatively unmodified from John's original concept. It handles cases where polymorphism prevents a static analysis from deducing what changes would be a pure refactoring or not. The provided dynamic refactoring is for a rename of a method with multiple implementors. The approach extends easily to other static ChangeMethodNameRefactorings when blocked by multiple implementors, and could be developed to handle a range of other cases.

The system wraps the call sites of the statically-unresolvable methods. The user can run test suites and/or exercise code by hand to call these sites and so let the system resolve the refactoring. They can also simply invoke operations on the list of call sites to tell the system the right answer - not provably a refactoring but sometimes fastest and safe enough in simple cases or to clear that last hard-to-reach but easy-to-diagnose call site. Thus the system generates a list of refactoring changes. The user can further inspect these and edit them, as for a static refactoring, before executing.

Tests check correct behaviour in a variety of polymorphically and hierarchically challenging situations.

The system fits naturally with the corresponding version of Tools-Refactoring Browser, replacing the static multiple implementors warning review option with the dynamic one (see the UI package's comment re adding a direct invoker if desired). Becaue the system depends on method wrappers, it is expected always to be a separately loadable and unloadable add-on, never becoming part of the Tools-Refactoring Browser base, since not everyone wishes to have method wrappers in their base IDE by default. Detailed instruction and cautioning scripts in the UI make users aware of the powers and perils of method wrappers.