Rearranger RFE: new group for implementing/overriding methods

Hi Dave,

First, thanks for the nice plugin.

Currently it is possible to create a rule for "Interface Methods". It
would be cool, if it also would allow a group for "Implementing Methods"
(no matter, whether interface or just abstract in the super-class) and
one for "Overriding Methods" (which override super-class methods).
Thanks in advance.

Tom

13 comments
Comment actions Permalink

Thanks, Tom. Can you clarify, so I'm sure I understand what you'd like --

You can currently specify a rule like
which will select any methods that implement or override a superclass or interface method.

1) Do you want the ability to differentiate between overriding a superclass method and implementing an abstract method?



The "Interface Method" rule was created so that methods could be sorted by interface, and tailored comments (containing the interface name) could be generated. It does not sound like you need this ability to group and generate tailored comments; rather, it sounds like you need only the ability to distinguish overriding and implementing attributes of methods. Suppose a class X has two superclasses Y and Z. Is it desirable to be able to group all of X's methods that override class Z methods separately from all of X's methods that override class Y's methods? I don't think so.

2) So I'm proposing to add one more condition to "Method" rules; besides static, abstract, final, overridden, overriding, etc. there would be "implementing". Implementing is distinguished from overriding as you describe.

Will that suffice?

-Dave

0
Comment actions Permalink

One more thought. IDEA distinguishes four categories of methods:

- overriding
- overridden
- implementing
- implemented

Perhaps I should add two more criteria to the current 'method' rule (implementing and implemented) and distinguish these from the first two.

0
Comment actions Permalink

1) Do you want the ability to differentiate between overriding a superclass method and implementing an abstract method?


Yes.

2) So I'm proposing to add one more condition to "Method" rules; besides static, abstract, final, overridden, overriding, etc. there would be "implementing". Implementing is distinguished from overriding as you describe.


+1, good idea.

Tom

0
Comment actions Permalink

Even better, although I do not need the "overridden" or "implemented" at
the moment, especially, because "implemented" is the same as "abstract"
or an interface method as long as a non-abstract subclass exist, which
should, because otherwise it makes no sense.

Tom

0
Comment actions Permalink

Hallo Tom,

Try version 3.3; I've added your overridden/overriding/ implemented/implementing criteria for methods, and show the corresponding icons in the confirmation and live rearrangement dialogs. Let me know if it gives you any trouble.
-Dave

0
Comment actions Permalink

Thanks, Dave, I'll give it a try.

Tom

0
Comment actions Permalink

Actually you'll need version 3.4. 3.3 wouldn't display any icons (except for me in my development environment...)

-Dave

0
Comment actions Permalink

Cool. The icons are back and Enter works as expected.

Thanks :)

(Now, the Ctrl-Up/Down still behaves weirdly but that's
ok..)

Vince.


0
Comment actions Permalink

In playing around with keystrokes and focus, I noticed a few things:

- As you press the tab key, the focus goes from the tree to scroll pane's vertical bar, horizontal bar, dialog's OK button, Cancel button, and back to tree. Unfortunately there's no default visual difference for the slider bars when selected. You just have to know, I guess.

- When focus is on a slider bar, up/down arrows and left/right arrows move the slider one increment. Page up/down moves an entire page, etc.

- Ctrl-up/down in the tree isn't documented in Swing to do anything, but for a table is described as "deselect selection". This seems to be what is happening. If one row is selected, ctrl-down leaves it outlined but unselected; ctrl-up reselects it. What is it you'd like or expect it to do?

-Dave

0
Comment actions Permalink

Regarding the scrollbars, you can make them non-focusable.

Tom

0
Comment actions Permalink

Yes, could do. Or could modify the paint() routine to do something to highlight them when focused.

But to make them non-focusable would mean being unable to control the scrolling with the keyboard. I guess I'll just leave it as is for now.

-Dave

0
Comment actions Permalink

But to make them non-focusable would mean being unable to control the scrolling with the keyboard. I guess I'll just leave it as is for now.


IIRC, moving the selection in the tree or table automatically scrolls it
into the visible area, so there is no need for moving a scrollbar
separately.

Tom

0
Comment actions Permalink

OK, I'm convinced. :) I'll make them unfocusable.

0

Please sign in to leave a comment.