| Summary: | Hierarchy view ignores interfaces [type hierarchy] | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Jared Burns <jared_burns> | ||||
| Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> | ||||
| Status: | RESOLVED WONTFIX | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | andreas.krueger, ashackleford, ggregory, lbreisacher, sja.eclipse | ||||
| Version: | 2.0 | Keywords: | helpwanted | ||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | other | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Jared Burns
This is an limitation in the type hierarchy view when opened on a package adding interfaces would result in a DAG and we have no widget to present such a structure. We can't fix this for 2.0 [type hierarchy] No action planned for 2.1 *** Bug 20962 has been marked as a duplicate of this bug. *** *** Bug 24004 has been marked as a duplicate of this bug. *** Hiding interfaces this way is *intensely* irritating. If we had bug voting (like the JDC) I'd burn all my votes on this one. Does a solution really require a new kind of widget? VAJ solved this with an Interfaces tab... I'd vote for this, too. I was about to file a bug report for this too, but a quick seached revealed that I was not alone. I'm not convinced that a DAG is needed. As Eclipse stands today you can look at a single interface and the classes that implement it. I don't see why you couldn't show multiple interfaces and their implementors in a single view. To help explain this I've created a mock-up of what I'd expect to see (see the attachment). Please realize that this is just an example and I'm not saying that this would fulfull everyone's requirements. The argument that a new widget is needed to implement this sounds like we are looking for a too complex solution to a relatively simple problem. While a DAG might be the "perfect solution", it is important to not allow it to stop us implementing a "pretty good" solution in the mean time. Clearly to implement an interfaces view as I am suggesting, a single class might very well appear multiple times in the view. This would be the case where a class is an implementer of multiple interfaces. Created attachment 3453 [details]
Mock-up of Interfaces view
I agree with Simon. In this case, a "pretty good" solution would be very useful. We could show interface inheritance with duplicates, or by just ignoring multiple superinterfaces. I just want to see those interfaces without hunting for 'em. To me there are two separate issues in adding interfaces to the H view: (1) Display the interface hierarchy. It is not displayed at all now. All I really want now is too see: IFoo IBar next to my: ClassA ClassB (2) A toogle/filter could let me tell eclipse whether or not I want the "implements" relationship displayed in the view as well, e.g., what the mock-up screen shot displays. IMHO, a good first step would be to just display the interfaces and /then/ to go argue about how to best display and implement the display of "implements" relationships. IMHO, the Types and Hierachy views should be folded into one with an additional toggle Flat/Hierarchical, just like in the Packages view. Please see http://dev.eclipse.org/bugs/show_bug.cgi?id=22552 Chaning state from assigned later to resolved later. Assigned later got introduced by the last bug conversion and is not a supported Eclipse bug state. As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you. |