Idea for function: Access hierarchy

Personally I would never use that.
IMHO non-private fields (of mutable or non-final type) are a Bad Thing anyway.
So when I found such a beast, I "Refactor -> Encapsulate Fields", then I am
sure that all access is in the class itself only, so highlight usages is enough.

Mikael Karlsson wrote:

Quite often I find myself investigating a field to find out
how it is used. I usually do this by doing Find Usages on the
field. Based on the result I go to each usage and examine that,
sometimes by using the Call Hierarchy.

I believe it would be possible to combine these actions into one
named Access hierarchy. When invoked on a field it would fill
a window with all places that access the field. The first level
would be all direct references to the field, including getter,
setter, and other access methods. Each of the methods would
be expandable to show the call hierarchy for that method.

I plan to enter this feature request into JIRA. Before that,
I'd be happy to hear any thoughts you may have.

/Mikael

Not to be a pill, Stephen, but the original poster said:

The first level
would be all direct references to the field,
including getter,
setter, and other access methods.

The point is that it wouldn't just show that there were is a getter/setter but that it would say WHO was calling the getter/setter functions.

And THAT, my friend, is a good IDEA.

Donald

I don't remember being your friend, but anyway dearest fellow:
This was just my opinion.
For methods you already can show a call hierarchy, so encapsulating
the field really helps.

In fact I think the proposed feature would be nice to have (it would
have the advantage of being able to recursively track all accessors of
the fields instead of going one by one).
So, feel free to file a Jira issue, nothing wrong with that.
IMHO there are many, many more pressing issues, but that's left for JetBrains
to decide.

Donald McLean wrote:

Not to be a pill, Stephen, but the original poster said:

>> The first level
>> would be all direct references to the field,
>> including getter,
>> setter, and other access methods.

The point is that it wouldn't just show that there were is a getter/setter but that it would say WHO was calling the getter/setter functions.

And THAT, my friend, is a good IDEA.

Donald

Actually, nothing in my suggestion said anything about the field
in question being non-private. Finding out who is using getters
and setters is equally relevant.