Community
Participate
Working Groups
Consider the following example: class A<E> { <T> void concat(A<E>, A<T>) } A<String> myA; myA.concat(p1, p2). Navigating with the method binding representing concat in myA.concat(....) will take you directly to A<E>#<T>concat(A<E>, A<T>). However it should take you first to A<String>#<T>concat(A<String, A<T>) from which we then can navigate to A<E>#<T>concat(A<E>, A<T>).
Forget to mention that I am talking about IMethodBinding#getMethodDeclaration
Alternatively we could have a second method.
IMO it's better to have getMethodDeclaration navigate directly to A<E>#<T>concat(A<E>, A<T>). That's for me the only one I really need to know (e.g. when I want to find the declaration node with compilationRoot.findDeclaringNode(binding)
I think you need both, and per contract #getMethodDeclaration() is doing the right thing for many clients. You would want an extra one to reach the intermediate one... #getGenericMethod() ? might be hard to come up with a pretty name.
Maybe, as suggested in title, #getConcreteGenericMethod() ? or more subtle: #getInstantiatedMethod() ?
What's about getParameterizedMethodDeclaration. This would somehow indicate that we are navigating to a parameterized type.
Note that this "stepwise type variable un-substitution" is in general not only a two-step navigation, since each enclosing type or method can declare more type variables. E.g. for class Outer<O> { class A<E> { <T> void concat(A<O> o, A<E> e, A<T> t) {} } } and Outer<Double>.A<String> myA; myA.concat(p1, p2, p3); , we have three steps towards the method declaration: Outer<Double>.A<String>#<Integer>concat(...) Outer<Double>.A<String>#<T>concat(...) Outer<Double>.A<E>#<T>concat(...) Outer<O>.A<E>#<T>concat(...) However, I currently don't have a better name for this either...
Is this still an issue ? Internal bindings allow to find both methods.
We currently don't need this method for 3.2, but I think it would still be handy to have it some time in the future. Another name suggestion: getGeneralizedMethod().
Defer post 3.2 since this requires an API addition.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
