Lava refactoring support

"Refactoring" has become a buzzword in today's software engineering discussion, and refactoring support is of growing importance for IDE's (Integrated Development Environments) that claim to be up-to-date.

"Refactoring" means to change and improve the structure of a program without changing its behavior. See, for instance, the Refactoring Home Page and the Refactoring discussion group at Yahoo. Several (mostly Java) IDE's are available now that provide either integrated refactoring support or a separate "Refactoring Browser"

In Lava, refactoring support is built-in from the beginning and integrated to the highest possible degree: It doesn't even appear as a special service but rather as a collection of parenthetical side effects of quite normal editing operations of the Lava structure editors:

Renaming of all kinds of Lava entities (classes, functions, variables etc.) uses the same entity-specific property sheets that are also used when you declare a new entity or when you change any other property of the entity. As a parenthetical side effect all references to this entity are changed correspondingly to show the new name of the entity. This is achieved by fetching the current name of the entity from its declaration at every point of reference; the declaration is found from a symbol table that is indexed by the immutable numeric internal identifiers of all symbols.
Moving/copying features (= member variables and functions) forth and back between base classes and derived classes or between classes and corresponding implementations uses the quite normal drag-and-drop or cut/copy/paste operations that are always used in Lava for restructuring the Lava declaration tree. Errors caused by refactoring operations are tolerated in cases where only the programmer knows how to circumvent or repair these in a meaningful way. (See also undo/redo support for drag-and-drop operations.)
Moving/copying other Lava entities uses these same drag-and-drop or cut/copy/paste operations. The fully qualified names of moved/copied entities, which reflect the nesting of packages and classes, are changed automatically as a parenthetical side effect.
Changing the number and/or order of the formal parameters of a function entails corresponding automatic changes of the actual parameter lists of all invocations of this function.
Introducing or removing accessor ("setter/getter") functions for member variables of a class is supported mainly by three specific measures:
- The same variable access syntax is used transparently for read/write access to member variables, no matter whether or not the access operation is based on setter/getter functions: Setter/getter functions are called only implicitly in any case. So the points of access to this variable need not be changed if setter/getter access is turned on or off.
- Default setter/getter functions are generated automatically in the implementation of the class to which the respective member variable belongs when setter/getter access is turned on.
- The Lava interpreter "knows" that within a setter/getter function access operations to the respective member variable must not recursively invoke the setter/getter functions but have to be performed directly.

Lava refactoring support

Other refactoring links