Method rename

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]... meaning-preserving
> transformation available *too* is a great thing, and I regret that I won't
> be able to use the RB (unless/until I succeed in hacking its guts).
> Examples of when I'd want the simple operation:
>...

Rather than reply to your points, I thought I'd spend the time on an
alternative implementation that your post inspired me with.

Instead of their being separate commands for the various renames, there is
only one, and a new "method rename" (as opposed to just "method name")
dialog that includes a drop-down list that allows one to select between the
following scopes:
    Class
    Hierarchy
    Package
    Global

The last 3 correspond to the former Rename/In Hierarchy, Rename/In Package,
and Rename/All commands. The "Class" scope means (in effect) this method
only, but it will also rename any references already established to that
name from that particular class. If even that is too much, then one must
save under a new name and delete the old method.

The same applies to the Rename References only refactoring (was that exposed
in the beta 2 UI? I don't think so), and the Add Parameter refactoring,
which previously was not scopable through the UI.

How does that sound as a compromise?

Regards

Blair

<snip>>
> Instead of their being separate commands for the various renames, there is
> only one, and a new "method rename" (as opposed to just "method name")
> dialog that includes a drop-down list that allows one to select between
the
> following scopes:
>     Class
>     Hierarchy
>     Package
>     Global
>
> The last 3 correspond to the former Rename/In Hierarchy, Rename/In
Package,
> and Rename/All commands. The "Class" scope means (in effect) this method
> only, but it will also rename any references already established to that
> name from that particular class. If even that is too much, then one must
> save under a new name and delete the old method.
>
> The same applies to the Rename References only refactoring (was that
exposed
> in the beta 2 UI? I don't think so), and the Add Parameter refactoring,
> which previously was not scopable through the UI.
>
> How does that sound as a compromise?
<snip>

Sounds good tome - any reason why you wouldn't just add "Method Only" or
something to the list, meaning only change the method but no references?

jlo

"Jeffrey Odell" <[hidden email]> wrote in message
news:[hidden email]...
> <snip>>
> > Instead of their being separate commands for the various renames, there
is
Because:
a) I am not convinced there is really a need for it (a save, history back,
delete sequence can be used, especially once this preserves the package of
loose methods).
b) It would not then be a RenameMethodRefactoring.

Regards

Blair

Blair,

> Instead of their being separate commands for the various renames, there is
> only one, and a new "method rename" (as opposed to just "method name")
> dialog that includes a drop-down list that allows one to select between
the
> following scopes:
>     Class
>     Hierarchy
>     Package
>     Global
[snip]
> How does that sound as a compromise?

That sounds great.  Dumb question: will selecting a range of packages in the
PB still rename in those packages?  That sounds like a very useful feature
which I think should be kept.  Any other flexibility over and above it is
most welcome.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:[hidden email]...
> Blair,
>
> > Instead of their being separate commands for the various renames, there
is the
> PB still rename in those packages?  That sounds like a very useful feature
> which I think should be kept.  Any other flexibility over and above it is
> most welcome.

Yes, of course.

Regards

Blair

Blair,

> How does that sound as a compromise?

Sounds reasonable to me.  I will continue to think that F2 should be bound
to a simple rename, rather than a refactoring, but it's not a big deal, and
your proposal certainly sounds like a better UI (safer *and* more flexible)
to the refactorings.

One question: does rename-in-hierarchy include superclasses ?  There's a
long-standing ambiguity in the Dolphin browsers, where the "local hierarchy"
is considered to include superclasses when browsing definitions, but not
when browsing references.

BTW, an idea for the future: how about interactive refactorings ?  You chose
a refactoring and get a list of candidates to be rewritten (with before and
after versions) and choose which ones you want the refactoring to apply to.
It wouldn't work with all the refactorings, but it might be particularly
useful for selector renaming.  Not something to mess around with now,
though.

> Blair

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> Blair,
>
> > Apart from reformatting of the referencing methods, what reason is there
> for
> > _not_ wanting the referencing methods rewritten. Surely the same
arguments
> > over behaviour preservation apply as for renaming methods. I'm prepared
to
> > believe there is a reason, I just can't think of one.
>
> One scenario that comes up reasonably often is this:
>
> I have a class named, say, NumberVariable.  I decide that, while its
> implementation is fine for Integer numbers, the concept should be
abstracted
> out, with the old class renamed to IntegerVariable and becoming a subclass
> of a new class named  NumberVariable.  All, or nearly all, references to
the
> old class should become refs to the new.  I then selectively move
> implementation "up" into the new class.
>
> It doesn't come up every day, but it does happen often enough that I want
to
> be able to handle it from the UI.  Indeed, I consider it a standard
> refactoring (I don't know if it's in the set the RB provides
> out-of-the-box).
>

Two approaches that spring to mind are:
a) Use 'Create Subclass' to create a new class "in between", then push stuff
up. This would mean visiting the class refs to rename individually, though
typically this is neither onerous nor prone to error.
b) Just add a subclass then selectively push methods and instance variables
down.

In the circumstances you describe (b) would probably be best. I am sure
there are other ways.

Regards

Blair

Blair,

> Two approaches that spring to mind are:
> a) Use 'Create Subclass' to create a new class "in between", then push
stuff
> up. This would mean visiting the class refs to rename individually, though
> typically this is neither onerous nor prone to error.
> b) Just add a subclass then selectively push methods and instance
variables
> down.

Sure, but neither of these deals with the fact that I'd want to rename the
class without changing all the methods that refer to it (even apart from the
rewriting/formatting issue).  I'd want to recompile them, yes, but nothing
else.  I can do that in D4, but if you remove the ability to rename a class,
without changing its references, from the D5 UI, then it's going to be
inconvenient.

> Blair

    -- chris