Re: Push down instance variable in RB not working

"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 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.
>
>