Summary: | [call hierarchy] Suggestion for extension of call hierarchy | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Jens Odborg <jens.odborg> | ||||
Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> | ||||
Status: | ASSIGNED --- | QA Contact: | |||||
Severity: | enhancement | ||||||
Priority: | P3 | CC: | daniel_megert, eclipse, markus.kell.r, pavol.zibrita | ||||
Version: | 3.0 | ||||||
Target Milestone: | --- | ||||||
Hardware: | PC | ||||||
OS: | Windows 2000 | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Jens Odborg
2003-11-20 15:33:11 EST
I like the idea of honoring dynamic binding in the call hiararchy, but adding reimplemented methods as children to the tree will make the tree clumsy. From a user perspective I most of the time follow one call path. So I would like to have the choice to exchange one node in the hierarchy with a super or sub implementation. Jesper, what do you think about this? I under stand you consern making the tree clumpsy
When I wrote this proposal I actually considered:
Calls from method:
Having "f()"s overridden implementaitions located in a child of "f()" lable
e.g. "overridden implementations"
Calls to method:
but then using a similar approach for "g()" saw a little pointless since "g()"
typical only have one super implementaion (except when an implementation
honnors several interfaces)
at that point I saw the extra tree levels as a bigger issue
I am not sure what exacly you mean with:
> So I would like to have the choice to exchange one node
> in the hierarchy with a super or sub implementation.
but if mean replacing the node so the old node is deleted and a new is created
then I not sure I like it, I see the folowing problem:
some times there are several sub implementations and I would like to wisit them
one at the time until I find the one I search, and the visibility of the other
nodes tell me somthing about where I have already been
I guess for to see what works best some mockups are needed.
I just got an idea what do you think about adding check boxes to all nodes
signalling whether or not to show sub/super implementation as sibling?
(sub in calls from methods and super in calls to method)
There must of course be a hint text for the checkbox describing its purpose
I would not exchange the node, but let the user replace it with a special "Show overriding methods" node. That special node could then show all overriding methods as children. Created attachment 8074 [details]
MockUp (quick and dirty screenshot C&P)
This picture shows the "special node" for the method
run(TestResult): void - junit.framework.Test
and its overriding methods (including the original method itself) as children.
I use the call hierarchy a lot. The option to see overrides is a must in some cases, it's much harder to do some refactorings without it. I would give you 10$ when it is implemented. Maybe u can use http://www.bidforfix.com/ |