Community
Participate
Working Groups
In Eclipse it is very convinient to browse and navigate the sources with mouse and CTRL key. When a method where one tries to navigate is declared in an interface, Ecplise always goes to the declaring interface. Popup window where a concrete implementation of that method could be chosen would allow one to go directly to the implementation class.
There are plans to investigate such a behavior for hovers. This could probably applied to [modifier] + click as well.
You can use Ctrl+T.
*** Bug 197349 has been marked as a duplicate of this bug. ***
Is there any plan to address it any time soon. May be as a patch to Europa?
We'll see what we can do for 3.4.
*** Bug 206685 has been marked as a duplicate of this bug. ***
Note: bug 206685 contains a patch implementing a suggestion
We'll see how much we have to do during RC1.
*** Bug 256152 has been marked as a duplicate of this bug. ***
*** Bug 259038 has been marked as a duplicate of this bug. ***
(In reply to comment #10) > *** Bug 259038 has been marked as a duplicate of this bug. *** > Thanks for marking the duplicate, apologies I didn't find the original bug myself. Just a quick comment is that the resolution I had in mind for the bug I raised is slightly different to what's described in this bug report. Specifically, the concept of Eclipse remembering which implementation class you were last on and picking that by default. I'd prefer that to popping up a list of implementing classes. Crucially, I almost always want to go back to the implementing class that I was last looking at. However, for a totally consistent approach we need to consider the more complex case of when a method definition is in a *subclass* of the class you were last browsing. In that case, a popup will be required to navigate to the correct implementation subclass. It sounds really complex, but I think it could work well in practice.
I saw your ideas but there are no plans to add LRU behavior for that. Note that you are free to provide your own hyperlink detector which does this.
Created attachment 126695 [details] Ctrl+click now shows the implementation for methods.
Hi Raksha, the patch is not good: - it gives NPE for methods without a receiver (i.e. for foo() instead of t.foo()) - it logs an error each time there's more than one match Some minor issues: - always log before doing work (I already mentioned that previously) - don't catch OperationCanceledException - only log in case of errors (not when interrupted) - the new createHyperlink method can return 'null' but that's not documented - in JavaElementHyperlinkDetector you define "IHyperlink link;" in the wrong scope as it is only used inside the for-loop - two of your new strings are missing the JavaElementImplementationHyperlink_ prefix - as you can see from the class name we write "canceled" not "cancelled" NOTE: we use American English and not British English - the hyperlink class has a warning (non-localized string) - the operation canceled string is not needed: simply use the 0-arg constructor - openTypeHierarchyForEditorInput has no Javadoc - openTypeHierarchyForEditorInput is not a good name, use openQuickHierarchy instead - check 'type' for null at the top - Searching all method declarations.. misses a third '.' NOTE: better would be "Searching for implementors of ''{0}''..." and fill in the element
Created attachment 126838 [details] Patch with review changes.
Sorry, but I have to reject the patch as several of my previous comments are still not fixed. >- the new createHyperlink method can return 'null' but that's not documented Still not correct: 1. such things must be documented in @return (or @param for parameters). 2. it must be documented in the super class not in the subclass - one file has a warning. - local variables are still not declared closed to where they are used Some other things: - in case of a real exception (InvocationTargetException) we must not continue - you could move the add - why do you use Modifier.isAbstract instead of using Flags?
>- you could move the add Forget about this (copy/paste problem)
Created attachment 126960 [details] Made the minor changes.
Created attachment 126961 [details] Pls take this one.
The patch is good. I committed it with some improved Javadoc and formatting. There are some further issues that we need to look at: - bug 266443: [navigation] JavaElementImplementationHyperlink does not work for method declarations - bug 266442: [navigation] JavaElementImplementationHyperlink.open() must show dialog in case of error
*** Bug 131537 has been marked as a duplicate of this bug. ***
