Method rename

I was very pleased to see that method rename is now implemented, but I have
a small request:

Can we have an option to rename the method *without doing anything else*
please.  I.e. without rewriting any of the methods that use that name, nor
the body of the method itself.  In particular I think that F2 should be
bound to an operation which renames the method, but doesn't do *anything*
else (at least without prompting).

A general point, related to this.  This is the first time I've used the RB,
and I'm rather disappointed -- In fact I'm finding that it isn't suiting me
at all.  I suspect that when the beta is over I'll be looking to remove the
RB entirely from my working system.

It's not that I don't like the idea of the RB, but it is a great deal too
willing to re-write my code in ways that it thinks are better.  To such an
extent that I don't think I'll be able to use it.

As far as I can see it's not possible (without a *great* deal of work) to
"fix" it so that it is willing to believe that my formatting was correct in
the first place, and to do its re-writes without disturbing more of my very
careful layout than necessary.  This is nothing to do with having a
configurable layout engine -- that'd be fine and good and very welcome (and,
in any case it doesn't look difficult to write a formatter which used my
conventions).  The problem is that any re-write does invoke the layout
engine, which (like any layout engine) necessarily throws away layout
information (and syntactic info too, in this case, such as logically
unnecessary brackets), and I am finding that unacceptable.

Not that I expect you, or anyone else, to fix this.  It's just a bit of
general feedback.  (And a bit of a whinge.)

    -- chris

Chris,

> As far as I can see it's not possible (without a *great* deal of work) to
> "fix" it so that it is willing to believe that my formatting was correct
in
> the first place, and to do its re-writes without disturbing more of my
very
> careful layout than necessary.  This is nothing to do with having a
> configurable layout engine -- that'd be fine and good and very welcome
(and,
> in any case it doesn't look difficult to write a formatter which used my
> conventions).

That's something I would welcome, and would probably take time to tweak to
be more to my liking.


> The problem is that any re-write does invoke the layout
> engine,

That seems almost unavoidable, though I'll admit I haven't read a line of
the RB code.


> which (like any layout engine) necessarily throws away layout
> information (and syntactic info too, in this case, such as logically
> unnecessary brackets), and I am finding that unacceptable.

I don't care for the accepted formatting conventions either, but, I have a
big refactoring job coming up soon, and I'm finding the help in refactoring
to be worth the unwanted formatting changes.  Reading the RB's output is
really no different from reading code written by other programmers, and the
alternative is to do my own refactoring, so I think it's worth adapting.
Besides, if I'm going to spend a lot of time looking at a method, I can
always reformat it my way after the RB has done its work.  Most of my
discontent has to do with formatting of blocks for which I like to have the
closing bracket indented to show the nesting level, and that's pretty easy
to fix if it happens to bother me.

Have a good one,

Bill

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

I wrote:

> Can we have an option to rename the method *without doing anything else*
> please.  I.e. without rewriting any of the methods that use that name, nor
> the body of the method itself.  In particular I think that F2 should be
> bound to an operation which renames the method, but doesn't do *anything*
> else (at least without prompting).

ARGHH!!!

I've just realised that class rename now does the same thing too.

I'm sorry, but I find this totally unacceptable.  How can I prevent it ?  If
doing so means loosing the RB entirely, then I'm willing to pay that price.

Please take this seriously, this really matters to me!

    -- chris

P.S.   For now, I've removed RefactoringSmalltalkSystem>>renameClass:to: and
made SmalltalkFormatter class>>new do an assert: [false] (which I can resume
if I want to).

Chris,

> > Can we have an option to rename the method *without doing anything else*
> > please.  I.e. without rewriting any of the methods that use that name,
nor
> > the body of the method itself.  In particular I think that F2 should be
> > bound to an operation which renames the method, but doesn't do
*anything*
> > else (at least without prompting).

Please correct me if I'm missing something, but, isn't the point of a method
rename to do all of the rewriting of the senders?  Otherwise, you can just
accept a new method.  The same would (I think) apply to adding a parameter -
to do it w/o the rewrite, just add the parameter yourself and reaccept and
then selectively modify senders of the old method.


> I've just realised that class rename now does the same thing too.
>
> I'm sorry, but I find this totally unacceptable.  How can I prevent it ?
If
> doing so means loosing the RB entirely, then I'm willing to pay that
price.

This strikes a little closer to home.  I can envision wanting to rename a
class without having all callers recoded.  Blair, for classes, would it be
possible to introduce a "rename only" option that would skip the
refactoring?

Have a good one,

Bill

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

Bill,

> Please correct me if I'm missing something, but, isn't the point of a
method
> rename to do all of the rewriting of the senders?  Otherwise, you can just
> accept a new method.  The same would (I think) apply to adding a
parameter -
> to do it w/o the rewrite, just add the parameter yourself and reaccept and
> then selectively modify senders of the old method.

Yes, that would be exactly the point of the method rename *refactoring*, but
I want -- and I think F2 should be bound to -- a simpler rename operation
(for both classes and methods).

The point of the simple operation is that it would preserve the owning
package of the method, whereas edit-save-accept adds the new method to the
owning class's package.  So, say I have  a loose method on View called
#goBellyUp which is in my 'CU Hacks' package; I decide that the name's not
really poetical enough, so I edit it to #goTitsUpwards, and save it.  The
new method has now been added to the 'Dolphin MVP Base' package. So I now
have to go and change the package of the method to 'CU Hacks', *and* decide
whether I really had changed 'Dolphin MVP Base', and if not then remove its
changed flag.

Since I use a fair number of loose methods, and am a vigorous refactorer,
that's a little dance I go through rather too often.

I asked sometime ago (on the main ng) for an enhancement to provide a
save-and-replace operation which would preserve the method's owning package.
Thinking about it now, it seems to me that it might be easier if
edit-and-save always preserved the method's package (just as it does the
method categories).  I don't think it'd be too common for anyone to want to
use the edit-save thing on a loose method without wanting the new method to
share the old one's package.  And if they did, then there's the feedback
about loose methods these days to act as warning.

Andy, Blair, how do you feel about that ?  It'd be a good deal easier to
implement than a non-RB rename operation, I suspect.  Anyway I've duplicated
the suggestion on the main ng to see what more people think of the idea (I
haven't mentioned the RB, of course).

> Bill


    -- chris

FWIW - I agree that the class/method renames in the list should do a basic
rename, and the refactoring style renames should be executed by selecting a
specific refactoring operation.

That being said, getting the code formatter flexible enough that it writes
code the way you want is a huge advantage when refactoring code.  I hope to
have some time to look at it and coax it too understand my whims...

jlo

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> I was very pleased to see that method rename is now implemented, but I
have
> a small request:
>
> Can we have an option to rename the method *without doing anything else*
> please.  I.e. without rewriting any of the methods that use that name, nor
> the body of the method itself.  In particular I think that F2 should be
> bound to an operation which renames the method, but doesn't do *anything*
> else (at least without prompting).
>
> A general point, related to this.  This is the first time I've used the
RB,
> and I'm rather disappointed -- In fact I'm finding that it isn't suiting
me
> at all.  I suspect that when the beta is over I'll be looking to remove
the
> RB entirely from my working system.
>
> It's not that I don't like the idea of the RB, but it is a great deal too
> willing to re-write my code in ways that it thinks are better.  To such an
> extent that I don't think I'll be able to use it.
>
> As far as I can see it's not possible (without a *great* deal of work) to
> "fix" it so that it is willing to believe that my formatting was correct
in
> the first place, and to do its re-writes without disturbing more of my
very
> careful layout than necessary.  This is nothing to do with having a
> configurable layout engine -- that'd be fine and good and very welcome
(and,

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> I wrote:
>
> > Can we have an option to rename the method *without doing anything else*
> > please.  I.e. without rewriting any of the methods that use that name,
nor
> > the body of the method itself.  In particular I think that F2 should be
> > bound to an operation which renames the method, but doesn't do
*anything*
> > else (at least without prompting).
>
> ARGHH!!!
>
> I've just realised that class rename now does the same thing too.
>
> I'm sorry, but I find this totally unacceptable.  How can I prevent it ?

Either uninstall the 'Dolphin Refactoring Browser' package, or evaluate:
    SmalltalkSystem current becomeA: SmalltalkSystem

> If doing so means loosing the RB entirely, then I'm willing to pay that
price.
> Please take this seriously, this really matters to me!

Of course, but I do recommend you persevere. YMMV but as we've got more and
more into refactoring, we've found that laying out code by hand, like method
comments, just gets in the way. I'm going to resist saying any more than
that because its a off-topic for this newsgroup. I think the whole issue of
code (re)formatting by the Refactoring Engine should be aired in a more
public forum, the debate would be more varied anyway.

I'll just add (because it is on-topic for this newsgroup) that beta 3 will
include the configurable formatter which John kindly sent me (as well as
making a few aspects of the standard formatter, such as max line length,
configurable options), and one's default formatter will *optionally* be used
to format all methods as and when they are viewed in the browsers. This will
allow every Dolphin user to view other people's source in their own
preferred format.

Regards

Blair

"Blair McGlashan" <[hidden email]> wrote in message
news:[hidden email]...
>
> Either uninstall the 'Dolphin Refactoring Browser' package, or evaluate:
>     SmalltalkSystem current becomeA: SmalltalkSystem

Sorry, I don't know what I was thinking of. Just switching the development
system class will not be sufficient, since it will leave enabled a number of
commands that are no longer implemented. It is necessary to uninstall the
package.

Regards

Blair

Hi Blair,

> I'll just add (because it is on-topic for this newsgroup) that beta 3 will
> include the configurable formatter which John kindly sent me (as well as
> making a few aspects of the standard formatter, such as max line length,
> configurable options), and one's default formatter will
> *optionally*

:)


> be used
> to format all methods as and when they are viewed in the browsers. This
will
> allow every Dolphin user to view other people's source in their own
> preferred format.

Interesting.  Does the RB use it when it writes code, or does it work only
in the browsers?

Have a good one,

Bill

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

Blair,

> > If doing so means loosing the RB entirely, then I'm willing to pay that
> price.
> > Please take this seriously, this really matters to me!
>
> Of course, but I do recommend you persevere. YMMV but as we've got more
and
> more into refactoring, we've found that laying out code by hand, like
method
> comments, just gets in the way.

I've decided to remove all the RB packages for the remainder of beta2.
That's probably a configuration that should be beta'd anyway.

> I'm going to resist saying any more than
> that because its a off-topic for this newsgroup. I think the whole issue
of
> code (re)formatting by the Refactoring Engine should be aired in a more
> public forum, the debate would be more varied anyway.

I agree; although, for me, the real issue is not so much about refactorings
and rewritings, as the much more on-topic question of whether Dolphin should
bugger-up my layout when I *haven't* asked it to.

> I'll just add (because it is on-topic for this newsgroup) that beta 3 will
> include the configurable formatter which John kindly sent me (as well as
> making a few aspects of the standard formatter, such as max line length,
> configurable options)

I'm looking forward to it, and will try reinstating the RB in beta3.  I hope
it's got options like preserve-blank-lines, and dont-leave-whitespace-
at-the-end-of-lines ;-)

> and one's default formatter will *optionally* be used
> to format all methods as and when they are viewed in the browsers. This
will
> allow every Dolphin user to view other people's source in their own
> preferred format.

I hope that it'll turn out that you've done this in such a way that it's
relatively easy for me to add a filter such that it only formats the
presentation of *other people's* code.  I'm moderately serious about that
(it's easy enough to write the filter -- I'd use the owning package), and
I'm sure you can see how it's the kind of thing *I'd* want, but I doubt if
enough people would want anything similar to justify your adding to the
system.

> Blair

    -- chris

Chris,

My wish list for this would be to have the RB's output go through the
customized formatter before it's saved.  Then I _think_ I'd leave the
browser formatting off.

Have a good one,

Bill

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

"Bill Schwab" <[hidden email]> wrote in message
news:[hidden email]...
> ....
> > be used
> > to format all methods as and when they are viewed in the browsers. This
> will
> > allow every Dolphin user to view other people's source in their own
> > preferred format.
>
> Interesting.  Does the RB use it when it writes code, or does it work only
> in the browsers?

The configured formatter will be the one used within the browsers and for
code rewriting. However if one takes the option of auto-format when
browsing, then the latter is rather irrelevant (except, I suppose, to the
format of filed out code).

Regards

Blair

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> Blair,
>
> > > If doing so means loosing the RB entirely, then I'm willing to pay
that
True.

>
> > I'm going to resist saying any more than
> > that because its a off-topic for this newsgroup. I think the whole issue
> of
> > code (re)formatting by the Refactoring Engine should be aired in a more
> > public forum, the debate would be more varied anyway.
>
> I agree; although, for me, the real issue is not so much about
refactorings
> and rewritings, as the much more on-topic question of whether Dolphin
should
> bugger-up my layout when I *haven't* asked it to.

Ah, but you have. You asked it to perform a rename refactoring which
rewrites the code in all implementors and senders in order to preserve
behaviour. At present the rewrite engine reformats the entire method.

I wasn't intending on doing that, but I'll consider it.

Regards

Blair

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> ....
> I asked sometime ago (on the main ng) for an enhancement to provide a
> save-and-replace operation which would preserve the method's owning
package.
> Thinking about it now, it seems to me that it might be easier if
> edit-and-save always preserved the method's package (just as it does the
> method categories).  I don't think it'd be too common for anyone to want
to
> use the edit-save thing on a loose method without wanting the new method
to
> share the old one's package.  And if they did, then there's the feedback
> about loose methods these days to act as warning.
>
> Andy, Blair, how do you feel about that ?  It'd be a good deal easier to
> implement than a non-RB rename operation, I suspect.  Anyway I've
duplicated
> the suggestion on the main ng to see what more people think of the idea (I
> haven't mentioned the RB, of course).

As I mentioned in my reply in the main newsgroup we have decided to do that
enhancement.

Regards

Blair

Blair,

> The configured formatter will be the one used within the browsers and for
> code rewriting.

Excellent!


> However if one takes the option of auto-format when
> browsing, then the latter is rather irrelevant (except, I suppose, to the
> format of filed out code).

But it gives the option of presenting non-refactored code as it was, which
is welcome.

Have a good one,

Bill

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

"Bill Schwab" <[hidden email]> wrote in message
news:[hidden email]...
[re: Class rename also renames all references]
>
> This strikes a little closer to home.  I can envision wanting to rename a
> class without having all callers recoded.  Blair, for classes, would it be
> possible to introduce a "rename only" option that would skip the
> refactoring?

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.

Regards

Blair

Blair,

> > This strikes a little closer to home.  I can envision wanting to rename
a
> > class without having all callers recoded.  Blair, for classes, would it
be
> > possible to introduce a "rename only" option that would skip the
> > refactoring?
>
> 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.

A couple of times recently, I've had a class that I didn't name terribly
well, and found that "the right name was in the wrong place".  It turned out
to be easier to rename one class and then put back a class of the same name
with slightly different functionality.  It's not really refactoring, because
the behavior is expected to change.  With that said, I will probably end up
using the RB to do this kind of stuff because it will likely be easier to
chase down a few errant references to the wrong class than it would be to
insert a subclass or whatever else goes along with it.

If it's difficult to do, you might just put it down as an enhancement
request to see if it gets any traction.  OTOH, the functionality almost has
to exist in case the RB is uninstalled, right?

Have a good one,

Bill

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

"Bill Schwab" <[hidden email]> wrote in message
news:[hidden email]...
> Blair,
>
> > > This strikes a little closer to home.  I can envision wanting to
rename
> a
> > > class without having all callers recoded.  Blair, for classes, would
it
> be
> > > possible to introduce a "rename only" option that would skip the
> > > refactoring?
> >
> > 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.
>
> A couple of times recently, I've had a class that I didn't name terribly
> well, and found that "the right name was in the wrong place".  It turned
out
> to be easier to rename one class and then put back a class of the same
name
> with slightly different functionality.

Yes, but you'd still have to recompile all the refs to the one with the
wrong name (now the right name), because they will be referencing the
wrongly named class.

>...It's not really refactoring, because
> the behavior is expected to change.  With that said, I will probably end
up
> using the RB to do this kind of stuff because it will likely be easier to
> chase down a few errant references to the wrong class than it would be to
> insert a subclass or whatever else goes along with it.
>
> If it's difficult to do, you might just put it down as an enhancement
> request to see if it gets any traction.  OTOH, the functionality almost
has
> to exist in case the RB is uninstalled, right?
>

Indeed, see SmalltalkSystem>>renameClass:to:. Basically it amounts to:

    ClassBuilder renameClass: Object to: #MyObject

This basic rename is so much less useful than a behaviour preserving rename
that I am not convinced it is worth exposing through the UI, particularly
since it leaves the system in an inconsistent state in a way that a beginner
may not understand. I haven't missed it not being available in many months
of use.

Regards

Blair

Blair,

> > I agree; although, for me, the real issue is not so much about
> refactorings
> > and rewritings, as the much more on-topic question of whether Dolphin
> should
> > bugger-up my layout when I *haven't* asked it to.
>
> Ah, but you have. You asked it to perform a rename refactoring which
> rewrites the code in all implementors and senders in order to preserve
> behaviour. At present the rewrite engine reformats the entire method.

Ah, I begin to see where we are differing here.  I don't think F2 should
invoke a refactoring; that's to say I *don't* want it to invoke a
behaviour-preserving transformation.  Obviously, having a 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:

Because I've only just written a method, and I know that it isn't used from
elsewhere, but I don't want to have to think/worry/check whether there are
pre-existing users of another method with the same selector. (This happens a
lot, of course).

Because I've realised that a method shares a name with another method in the
same package, but doesn't share the meaning.

Because I'd called a method #at:, and now realise that was a mistake.

The transformation, of the other hand, is a much heavier-weight operation
(from my POV as a user), since it comes in varying scoped forms, and it will
have wider effects.  I will have to think, at least briefly, before using
the transformation, and so having a slightly more cumbersome (but more
flexible) UI to invoking it is acceptable.  Hence the system where the
rename refactoring is invoked from a menu with a pull-right list of scopes
is fine and appropriate.

So I don't think that F2 should be bound to the refactoring.  Mainly because
I think that F2 should be a quick and thoughtless operation.  Also you have
no way to choose the scope, and there is no feedback about what the scope
will be (which, BTW, I think is a flaw in the in current beta, regardless of
the other issue here).

But I'm only discussing (or "disputing" if you prefer ;-) what F2 should be
bound to.  You've said that edit-and-save will be beefed up to provide the
simple operation directly and that's great.  Thank you very much.

> > I hope that it'll turn out that you've done this in such a way that it's
> > relatively easy for me to add a filter such that it only formats the
> > presentation of *other people's* code. [...]
>
> I wasn't intending on doing that, but I'll consider it.

Thanks in advance.  (But don't bust a gut over it -- even I don't think it's
*that* important.)

> Blair

    -- chris

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

> Blair

    -- chris