Community
Participate
Working Groups
In the Quick Outline, pressing CMD+O twice should also reveal private members of super types (that is what it does in JDT).
Not sure about this: We're using the show inherited feature to show the visible members only, e.g. to show the complete set of multi dispatch methods for a given synthetic dispatcher. Also showing the overridden ones could be a bit confusing. We could also add a third mode (show all members) with the functionality form JDT.
Any other opinions? I'd vote for the third mode.
+1
I think it should behave like in JDT it at least never confuses me.
In JDT there are no dispatch methods, which is the main reason why we did the special implementation for Xtend: To see all dispatch cases for a specific given synthetic dispatcher, including those from super classes. If the Xtend quick outline showed even overriden dispatch methods I guess it would become *very* confusing. Personally, I am sometimes confused by JDT's quick outline, as it tends to not give you the closest implementation of an overridden method as the first match in a search.
I use it to quickly navigate even to overridden members. I think grouping dispatch methods improves the structure a bit but doesn't seem to conflict with showing all declared members in the type hierarchy. Maybe it depends on how and for what this feature is used. I typically also use the search field to quickly narrow down the number of shown elements.
(In reply to comment #4) > I think it should behave like in JDT it at least never confuses me. That's an interesting remark. I'm almost always confused by JDTs visualization, especially when it comes to unknown code bases / type hierarchies. If you consider the inherited #handleDispose in the class RichStringAwareSourceViewer or XFunctionTypeRefImplCustom#getType I'd select the wrong entry for sure. Especially if you compare the order in the quick outline when you filter for XFunctionTypeRefImplCustom#getType with XFunctionTypeRefImplCustom#getIdentifier. A mode which visualized all methods that are currently not overwritten would be nice.
Yes, ordering along the type hierarchy would be an improvement. Still overridden methods can be called and are called, so they shouldn't be hidden. I for one use it regularly to navigate to the different implementations in methods like 'isVariableDeclarationRequired(...)' in our compiler hierarchy.
Appears to be solved with the new outline impl.
Requested via bug 522520. -M.
