"Frank Gerhardt" <[hidden email]> wrote in message
news:[hidden email]... >Does the "push down instance variable" refactoring work for you? > >Here is what I noticed: >1. Select a superclass that has anInstVar >2. Select from the menu Class/Instance Variables/Push Down >3. Select anInstVar in the dialog that pops up >4. anInstVar gets removed from the superclass >5. BUT anInstVar doesn't show up in the subclasses!? I don't know if there is a bug in the Dolphin version. However, the push down instance variable refactoring will only push down the instance variable to those subclasses that reference the variable. If no subclasses reference the variable, then it will be removed. John Brant |
"Frank Gerhardt" <[hidden email]> wrote in message
news:[hidden email]... > On Mon, 03 Sep 2001 15:53:02 GMT, "John Brant" <[hidden email]> wrote: > > > I don't know if there is a bug in the Dolphin version. However, the push > > down instance variable refactoring will only push down the instance variable > > to those subclasses that reference the variable. If no subclasses reference > > the variable, then it will be removed. > > THAT's clever! It works as intended ;-) > > However, and that's a minor issue, I get some warnings on the Transcript that > the pushed down instance variable is undefined in the methods that reference > it. > > > Error: SpecialCircle>>c1: at line 3: undeclared 'c1' > > Error: SpecialCircle>>doSomething at line 2: undeclared 'c1' > > Error: SpecialCircle>>doSomething at line 2: undeclared 'c1' > > Since everything works these "errors" are misleading. That is because the refactoring uses the methods ClassDescription>>removeInstVarName: and ClassDescription>>addInstVarName: (and in that order) to 'move' the instance variable. These methods are implemented in Dolphin by invoking the ClassBuilder, which recompiles methods in the classes it rebuilds to reflect changes in the shape of the class. Clearly the removal of an instance variable will affect the class shape, and if the class' methods were not recompiled then some of them may be invalid. Since the refactoring first removes the instance variable from the superclass (which is sensible given that one can't redefine an instance variable in a subclass) when the ClassBuilder recompiles the class and its subclasses compilation errors will result for those subclass' methods that referred to the instance variable. I did think at first that this problem was due to an over-sophisticated implementation of #add/RemoveInstVarName: (i.e. using the class builder), since these are (I believed) low-level Smalltalk-80 methods that should probably just update the class information without triggering the recompilation. I assume the refactoring does its own recompilation so all it needs is the low-level update of the class (John?). However on checking VW and Squeak I see that they also use their own ClassBuilders to make the changes, and I would assume that these would also recompile the methods? If so perhaps they experience the same compilation errors but these are suppressed and not reported anywhere (or perhaps they are reported, I haven't tried it). Frank. |
I modelled my Dolphin RB port primarily on the VW RB done by
John and Don. Blair is correct that these erors are compiler warnings generated when the class structure is changed. "Blair McGlashan" <[hidden email]> wrote in message news:9n2ro2$4t006$[hidden email]... > "Frank Gerhardt" <[hidden email]> wrote in message > news:[hidden email]... > > On Mon, 03 Sep 2001 15:53:02 GMT, "John Brant" <[hidden email]> > wrote: > > > > > I don't know if there is a bug in the Dolphin version. However, the push > > > down instance variable refactoring will only push down the instance > variable > > > to those subclasses that reference the variable. If no subclasses > reference > > > the variable, then it will be removed. > > > > THAT's clever! It works as intended ;-) > > > > However, and that's a minor issue, I get some warnings on the Transcript > that > > the pushed down instance variable is undefined in the methods that > reference > > it. > > > > > Error: SpecialCircle>>c1: at line 3: undeclared 'c1' > > > Error: SpecialCircle>>doSomething at line 2: undeclared 'c1' > > > Error: SpecialCircle>>doSomething at line 2: undeclared 'c1' > > > > Since everything works these "errors" are misleading. > > That is because the refactoring uses the methods > ClassDescription>>removeInstVarName: and ClassDescription>>addInstVarName: > (and in that order) to 'move' the instance variable. These methods are > implemented in Dolphin by invoking the ClassBuilder, which recompiles > methods in the classes it rebuilds to reflect changes in the shape of the > class. Clearly the removal of an instance variable will affect the class > shape, and if the class' methods were not recompiled then some of them may > be invalid. Since the refactoring first removes the instance variable from > the superclass (which is sensible given that one can't redefine an > variable in a subclass) when the ClassBuilder recompiles the class and its > subclasses compilation errors will result for those subclass' methods that > referred to the instance variable. > > I did think at first that this problem was due to an over-sophisticated > implementation of #add/RemoveInstVarName: (i.e. using the class builder), > since these are (I believed) low-level Smalltalk-80 methods that should > probably just update the class information without triggering the > recompilation. I assume the refactoring does its own recompilation so all it > needs is the low-level update of the class (John?). However on checking VW > and Squeak I see that they also use their own ClassBuilders to make the > changes, and I would assume that these would also recompile the methods? If > so perhaps they experience the same compilation errors but these are > suppressed and not reported anywhere (or perhaps they are reported, I > haven't tried it). > > Frank. > > |
Free forum by Nabble | Edit this page |