Community
Participate
Working Groups
I would suggest that the call hierarchy to be extended in the following way: Calls from method: When a function “f()” from class “C” is listed as called (on form “f() - C”), then functions from derivered classes of “C” that overrides the method “f()” are listed as siblings of “f()” (e.g. on form “method that overrides C2.f()” with image “implements method from interface” or “overrides method from super class”) Calls to method: When a function “g()” from class “C2” have its callers listed then if it override a function in a supper class an additional pseudo caller are listed (e.g. on form “calls to super C.g()”) (There can be only one such super tree-child for a method since e.g. “calls to super IC.g()” would be a tree-child of “calls to super C.g()" and NOT an additional tree-child of “g() - C2”) I have suggested a different text form to make a better distinction between overrides and true calls Some people would properly want this off so a check option in filter and/or a toggle button in view header bar are needed.
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/
