Two Small Suggestions

Hello Forum,

After having worked with the System Browser, Class Hierarchy Browser,
and auto-complete, I have two small suggestions:

1) When renaming a method using "Refactorings" from the context menu, it
might be safer to set the default scope to something a little less
destructive than "Global," perhaps "Class" or "Method".  Speaking for
myself, when I right-click on a method to rename it, my mind is in the
mode of "method," not "global," as the context would suggest.  So
renaming the method is what I expect I've just done.  I have to make a
conscious effort to change the scope and, well, sometimes I must be
unconscious at the time :).  I have been bitten by this several times.

2) Would it be possible for auto-complete to highlight private methods
in, say, red?  IMHO, I think this would increase productivity by
allowing one to focus very quickly on the public interface(s), while at
the same time being informed of the private interface(s).  Since
auto-complete is an advisory tool of sorts, I think in general it should
conform to the advice given by classes.

Any thoughts?

Cheers,

Eric

Eric,

> 1) When renaming a method using "Refactorings" from the context menu, it
> might be safer to set the default scope to something a little less
> destructive than "Global," perhaps "Class" or "Method".
[]
> Any thoughts?

I would agree, Global is probably my least favourable option as well -
although I would prefer to use Package as the default choice.  If you want
to change the default then you can edit the method
RBScopedMethodName>>defaultScope or add an #onViewOpened method to the
RenameMethodDialog class (cleaner but takes a bit more work).

--
Ian

Use the Reply-To address to contact me (limited validity).
Mail sent to the From address is ignored.

Ian,

I apologize for the delayed response.  I have been most busy with
ActiveTreeModel.

I took the RBScopedMethodName>>defaultScope approach, the lesser
intrusive of your two suggestions.  I'm just not comfortable enough yet
to go tinkering with my image, no pun intended ;).

It works great.  Thanks for the direction.

Cheers,

Eric

menu, it
> > might be safer to set the default scope to something a little less
> > destructive than "Global," perhaps "Class" or "Method".
> []
> > Any thoughts?
>
> I would agree, Global is probably my least favourable option as well -
> although I would prefer to use Package as the default choice.  If you
want

"Ian Bartholomew" <[hidden email]> wrote in message
news:[hidden email]...
The reason it works as it does is because if you rename at any other scope
than global then you may not be carrying out a behaviour preserving
refactoring. Contrary to intuition it should actually be safer to rename at
global scope (ignoring external dependencies such as stuff saved in binary
filed images), because you shouldn't break anything.

I think Chris suggested ages ago that an F2 rename of a method (or perhaps a
click-on-already-selected initiated rename) should result in an in-place
rename that would work only at method scope. This seems sensible to me
(there would be a one-off warning message that you might be about to break
something by renaming an individual method).

Regards

Blair

Blair,

>
The reason it works as it does is because if you rename at any other
scope than global then you may not be carrying out a behaviour
preserving refactoring. Contrary to intuition it should actually be
safer to rename at global scope (ignoring external dependencies such as
stuff saved in binary filed images), because you shouldn't break
anything.
>

The problem, though, lies with polymorphic message sends.  For example,
I renamed a method which I had called #at:put to #atChild:put (which I
later reversed), and the refactoring agent renamed #at:put everywhere in
the class.  As a result, <objectNodeMap at: put:> was renamed to
<objectNodeMap atChild: put:>, except that #at:put in this case came
from a variant of Dictionary, not my class, nor was it the target of my
refactoring.  Fortunately, I had selected "Class" as the scope, not
something broader.

As you point out, too narrow a scope could break the refactoring (which
I have also experienced).  But it seems that too broad a scope could
break the image.  Perhaps showing a checkable list of changes about to
be made before committing the refactoring would be a good middle ground.
I have seen this in other IDEs in the context of find-and-replace, and
it would seem to be consistent with Dolphin's design paradigm (e.g.
showing a list of dependencies when attempting to delete a variable,
etc.).

But I do like Chris's "F2" suggestion, as well as the edit-in-place
(EIP) suggestion.  EIP would be consistent with Dolphin's approach to
renaming variables.

Since this suggestion is probably a matter of taste, I think Ian's
approach of making a minor change in the image is acceptable.  Or
perhaps it could be relegated to a user preference.

Cheers,

Eric

menu,
> it
> >> might be safer to set the default scope to something a little less
> >> destructive than "Global," perhaps "Class" or "Method".
> > []
> >> Any thoughts?
> >
> > I would agree, Global is probably my least favourable option as well
-
> > although I would prefer to use Package as the default choice.  If
you
> want
> > to change the default then you can edit the method
> > RBScopedMethodName>>defaultScope or add an #onViewOpened method to
the
> > RenameMethodDialog class (cleaner but takes a bit more work).
> >
>
> The reason it works as it does is because if you rename at any other
scope
> than global then you may not be carrying out a behaviour preserving
> refactoring. Contrary to intuition it should actually be safer to
rename
> at
> global scope (ignoring external dependencies such as stuff saved in
binary
> filed images), because you shouldn't break anything.
>
> I think Chris suggested ages ago that an F2 rename of a method (or
perhaps
> a
> click-on-already-selected initiated rename) should result in an
in-place
> rename that would work only at method scope. This seems sensible to me
> (there would be a one-off warning message that you might be about to
break
> something by renaming an individual method).
>
> Regards
>
> Blair