The abstract instance variable refactoring is available from the "SourceCode" menu when you have selected an instance variable. It is also available from the "Variables" menu in the class definition when you have selected an instance variable. Finally, it is available from the "Class"->"Instance Variables" menu
Similarly, the abstract class variable refactoring is available from the "SourceCode" menu when you have selected a class variable. It is also available from the "Variables" menu in the class definition view when you have selected a class variable. Finally, it is available from the "Class"->"Class variables" menu.
Safety: The abstract variable refactorings are safe under normal circumstances.
The add parameter refactoring is available from the "SourceCode"->"Other"->"Add Method Parameter..." menu item.
Safety: The add parameter is relatively safe assuming that the code that is added as a parameter is safe (i.e., the code doesn't have side-effects). One area where it would be unsafe is to add a parameter to a method that is #perform:ed since we can't determine where the method is performed from (and the refactoring changes the name of the method).
This refactoring is available from "Class"->"Other"->"Convert to Sibling". It is enabled, if a single class is selected, which contains at least one subclass.
Safety: This refactoring could fail if you check the class hierarchy of the superclass, since the class hierarchy is changed for the new class.
Before conversion of A to a sibling:
A
+----+----+
| | |
B C D
After:
N
|
+----+--+--+----+
| | | |
A B C D
This code generator refactoring is available for individual variables (select one or more) from the "Variables"->"Convert to ValueHolder" menu.
Safety: This refactoring changes the behavior, if a corresponding message response is already inherited by a superclass.
This code generator refactoring is available for individual variables (select one or more) from the "Variables"->"Generate"->"Access Methods" menu. It is also available from the "Class"->"Generate"->"Access Methods" menu, here, accessors for all variables are generated.
Safety: This refactoring changes the behavior, if a corresponding message response is already inherited by a superclass.
In the browser, select a literal constant and choose this refactoring from the code menu.
Depending on the chosen replacement, class- or instance variables are added, and the corresponding
initialize method is updated to properly set the variable. Then all references to that constant are reqritten
to access the variable instead.
You can also choose to rewrite the literal into a getter-call to either the instance or the class side.
In that case, a corresponding getter method is created.
Safety: This refactoring changes the behavior, if a corresponding message response is already inherited by a superclass or redefined in a subclass. Use this if the same constant occurs multiple times within a class, or when it needs to be visible in other classes via a getter (typically, on the class side).
The browser will determine if it is legal to extract the method by checking for return statements and
temporary variable assignments.
If everything is OK, it will prompt you for a method name.
In this dialog, you can enter the new selector with the appropriate number
of arguments (listed in the list box below the selector).
You can also reorder the parameters from this dialog.
Select a parameter and use the arrow buttons
to move the parameter up or down in the list.
The browser will ask for any additional information, which is required to execute the refactoring.
This refactoring is available when you have selected the code of an expression (in the editor) that is used as part of another expression. After you have selected the expression, select the "Code"->"Extract to Temporary" menu choice.
Safety: Since this refactoring can change the evaluation order of the overall expression,
it is not safe if there are side effects
between those expression that are evaluated before the selected expression and the selected expression itself.
The refactoring fails, if the new temporary name hides an existing variables name
(because this makes the code more error-prone)
This refactoring is available from the "Selector"->"Refactor"->"Inline All Self Sends" menu when you select a message in the method list.
Safety: This refactoring is fairly safe.
This refactoring is available from the "Code"->"Inline Method" menu when you select a message send in the code.
Safety: This refactoring is fairly safe. If the refactoring finds something that it considers unsafe, it will warn you before performing the refactoring. If you proceed through the warning it will still inline the method.
This refactoring is available both from the "Source"->"Inline Method Parameter" and the codeviews "Code"->"Inline Method Parameter" menu, after you have selected the text of a parameter of the method in the codeView.
Safety: This refactoring is safe except when performing methods, since we can't convert the symbols that are performed (the name of the method is changed by this refactoring).
This refactoring is available from the "Selection"->"Inline Temporary" when you have an assignment statement selected.
Safety: This refactoring can be unsafe if the code you are inlining has side-effect or if any code between the assignment statement and the references have side effects on the inlined expression.
This refactoring is available from "Class"->"Move"->"Insert Common Superclass". It is enabled, if at least one class is selected, and all selected classes have a common superclass.
Safety: This refactoring could fail if you check the class hierarchy of the superclass, since the class hierarchy is changed for the new class.
Before insertion of N as a new superclass of A, B and C:
S
+----+----+
| | |
A C D
After:
S
|
N
|
+----+----+
| | |
A C D
This refactoring is available from "Selector"->"Move"->"To Component".
Safety: This refactoring is safe assuming you select the correct class(es) of the variable that should contain the new method.
This refactoring is available from "Selection"->"Move to Inner Scope" when you have selected a temporary variable in a method.
Safety: This refactoring is safe unless someone is looking at the source code.
Safety: This refactoring is safe and improves portability of your program.
This refactoring is available from "Class"->"Instance Variables"->"Concrete".
Safety: This refactoring is essentially an Inline All Self Sends, so it contains all the safe restrictions as Inline All Self Sends has.
The pull up instance variable refactoring is available from the "Class"->"Instance Variables"->"Pull Up" menu. It is also available as "Push up" when you have selected the variable in either the class definition or a method under the "Variables" and "Selection" menus.
Similarly, the pull up class variable is available from the "Class"->"Class Variables"->"Pull Up" menu. It is also available as "Push up" when you have selected the variable in either the class definition or a method under the "Variables" and "Selection" menus.
Safety: This refactoring is not safe if you code that depends on the exact layout of the class. Such code normally uses the #instVarAt:{put:} methods.
The push down instance/class variable refactoring is available from the "Class"->"Instance/Class variables"->"Push Down" menu, and also from the "Variables"->"Push Down" menu when the variable is selected in the class definition.
Safety: This refactoring is safe unless one is accessing the variable using the #instVarAt:{put:} methods.
The push up method refactoring is available from the "Selector"->"Move"->"Pull Up" menu.
Safety: This refactoring is safe assuming that every class that sends #subclassResponsibility is abstract.
The push down method refactoring is available from the "Selector"->"Move"->"Push Down" menu.
Safety: This refactoring is safe assuming that every class that sends #subclassResponsibility is abstract.
The remove class refactoring is available from the "Class"->"Safe Remove" menu.
Safety: This refactoring is safe if they are no indirect references to the class. Such references maybe from the #subclasses method or from performing "Smalltalk at: ...".
Before removal of A:
S
|
A
+----+----+
| | |
B C D
After:
S
+----+----+
| | |
B C D
This refactoring is available from the "Selector"->"Safe Remove" menu.
Safety: This refactoring is not safe if you have constructed selectors that perform the method (e.g., "self perform: 'foo' asSymbol). However, if you have code such as "self perform: #foo" then it will consider the #foo method referenced.
This refactoring is available both from the "Source"->"Remove Method Parameter" and the codeviews "Code"->"Remove Method Parameter" menu, after you have selected the text of a parameter of the method in the codeView.
Safety: This refactoring is not safe when you are performing the method (the name of the method is changed by this refactoring). Also, it is not safe if the parameter that is removed, has side-effects at one of its call sites.
The remove instance variable refactoring is available from the "Class"->"Instance variable"->"Remove..." menu as well as the "Variables" menu.
Similarly, the remove class variable refactoring is available from the "Class"->"Class variable"->"Remove..." menu as well as the "Variables" menu.
Safety: This refactoring is safe under normal circumstances. However, if you have code that depends on the layout of the classes, then it may not be safe.
This refactoring is available from "Class"->"Rename".
Safety: This refactoring is safe except when you have indirect class references (e.g., "Smalltalk at: 'Foo' asSymbol").
This refactoring is available from "Selector"->"Rename".
Safety: This refactoring is not safe for constructed selectors that are perform:ed. Also, if you reorder the parameters, this refactoring will not be safe if the parameters have side-effects on each other.
Notice that this operation is also able to change the order of the methods arguments (and rewrite all senders).
This refactoring is available from the code editors "Code"->"Rename Local Variable" menu when you have a temporary variable or argument selected.
Safety: This refactoring is completely safe, unless someone is looking at the source code for the method.
The rename instance variable refactoring is available from the "Class"->"Instance Variables"->"Rename" menu, and also the "Variables" menu.
Similarly, the rename class variable refactoring is available from "Class"->"Class variables"->"Rename" or the "Variables" menu.
Safety: This refactoring is safe except for classes that depend on the class layout since the positions of the variables may change.
This refactoring is available from the "Code"->"Convert to Instance Variable" menu, after you have selected the text of a temporary variable.
Safety: This refactoring is not safe if the method that defines the temporary is a recursive method.
Copyright © 2000 eXept Software AG, all rights reserved
<info@exept.de>