Re: Push down instance variable in RB not working

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Push down instance variable in RB not working

John Brant
"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


Reply | Threaded
Open this post in threaded view
|

Re: Push down instance variable in RB not working

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


Reply | Threaded
Open this post in threaded view
|

Re: Push down instance variable in RB not working

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