Refactoring - how to pull up a variable?

I am introducing a super class to two existing classes (Season and RacingActor)
both of which have a name variable with getter/setters.

I was expecting to find an easy refactoring to extract the name variable
(and its setter/getters) into the superclass - but nothing seems to do this
in one step - and in fact it looks like about 5+ steps to do it (making it
faster to do the thing manually).

I thought maybe "Abstract" refactoring might do it (but I have no clue what
that does?). I thought maybe I could push up a variable from my RacingActor
class - but its not there (you have to go to the superclass and use pull
up - which I find confusing - although I guess I can put up with it).

Having gone to the superclass - and used PullUp on my name variable, it just
moves the instance variable - and leaves the getter/setters alone (so whats
the point of that?) - I'm also still left with the the same situation in
the other subclass.

As this is a pretty simple behavior preserving transformation I am suprised
I can't see the obvious thing - but as is quite often the case maybe its
under my nose?

Is there a 1 step operation? Or how many steps can people do it in?

Tim

Tim,
I've run into the refactorings not matching my assumptions as well. Some
of them, like Abstract, I still haven't figured out yet either. Some of
them, scare me ;)
Here's an earlier thread that can give insight into operation and naming
of the push/pull refactorings:
http://groups.google.com/group/comp.lang.smalltalk.dolphin/browse_thread/thread/a688a88f5462c106/df8716f927d9cd74
TinyURL since that monster URL will be useless:
http://tinyurl.com/pdcfo

Essentially it doesn't move the accessors since the methods in the
subclasses could contain different code. So it saves the effort of
removing the instvar from all the subclasses. I guess a good feature
request of add-on would be to have it take care of the accessors as well
if they are all alike. No idea how difficult that would be.

Take care,
John

"John Rubier" <[hidden email]> wrote in message
news:_cUrg.1939$[hidden email]...
Abstract is the coolest of the refactorings imo :) Some are taught to always
use indirect access and create accessors for all of their variables; marking
them private to instruct other objects not to call them. I'd rather use
direct access by default, as Kent Beck says, to improve readability and
shorten a classes definition. Only if I decide its time to add some
intelligence to the get/set, allow another object access, override and so
forth do I hit abstract on the variable and hey presto all of your direct
accesses are converted to indirect. It also creates the accessors too as
you'd expect; protect/concrete does the reverse.

So:
foo
    a := a + 5 (direct)

Becomes:

a
    ^a

a: anObject
    a := anObject

foo
    self a: self a + 5 (indirect)

Regards,
Chris

Hi Chris,

> Abstract is the coolest of the refactorings imo :)


Thanks for shedding light on that - it is a cool refactoring! In some ways
I wish there were some of this in the online help or some tooltips for some
of the refactorings.

As for pull-up, it looks like it will require some work on our parts to make
it work like it should work (and indeed, the java guys have definitely started
to overtake the original refactoring implementation which was for so long
quite a bit ahead of the curve).

Tim