Community
Participate
Working Groups
I200411050810 TypeBinding#getQualifiedName() doesn't do what its Javadocs promise. Differences I found: - #getQualifiedName() does not include type arguments, although the Javadoc says it should. #getName() already includes type arguments as well as type parameters, which suggests that #getQualifiedName() should also include both. - #getQualifiedName() for List's type argument in 'List<? extends Object>' returns 'java.util.? extends Object' instead of '? extends java.lang.Object'
- #getQualifiedName() for type variables is undefined
Jim, could you please specify what is expected for the type variables? Because we are in the bindings' world, I think for: class X<T> we should have: X<T extends java.lang.Object> Move it back to me when the spec is updated. I will take care of the implementation.
Type variables are covered by the actual documentation. * <li>For type variables, the fully qualified name is just the name of the * type variable (type bounds are not included). * Example: <code>"X"</code>.</li> This is what is implemented right now.
Fixed and released in HEAD. Regression test added.
Can we review that again? The Javadoc is still slightly inconsistent and I also have problems to use the current implementation, especially as we still don't have a method getRawType * <li>For type bindings that correspond to particular instances of a generic * type arising from a parameterized type reference, * the fully qualified name is the fully qualified name of the erasure * type followed by the fully qualified names of the type arguments surrounded by "<>" and separated by ",". * Example: <code>"java.util.Collection<java.lang.String>"</code>. -> erasure of Collection<String> is Collection<E> -> qualified name 'j.u.Collection<E><String> ? The open question I have is: What happens if a type is inside a generic type. class MyGeneric<A> { class MyInner {} } In type signatures, such inner types are referenced like a.b.MyGeneric.MyInner a; -> no type parameters for the outer types The current implementation returns a.b.MyGeneric<A>.MyInner, which is hard to use. (However consistent with the first sentence in the Javadoc)
Reopen. Need 77360 fixed before we fix this one.
Jim, Could you please clarify the specs with Martin? When this is done, move it back to me and I will take care of the implementation.
Jim, in our discussion here we can't agree on the right solution for getQualifiedName. In your opinion, what should be the use of this method from a model point of view.
These methods are trying to provide useful names for clients to display to users if they need to. It's hard to promise much more than that; in particular, we cannot promise that these names would necessarily be useful for inserting into source code. Howewever, the current specs for getName and getQualifiedName are confused. Here's a proposal for what they should do: 1) the name of a type (declaration) is the same regardless of whether it is generic. E.g., The binding for the declaration of Collection has name "Collection". 2) the name of a parameterized type reference includes the type arguments. E.g., The binding for Collection<String> has name "Collection<String>". 3) the name of a raw type reference is the same as the name of the type it references. E.g., The binding for a reference to Collection without type arguments has name "Collection". 4) the qualified name of a member type is prefixed by the qualified name of the enclosing type Examples: package p; class Gen<X> { class Inn { } } Gen<String> v1; Gen<String>.Inn v2; Gen v3; Gen.Inn v4; ITypeBinding for declaration of Gen name "Gen" ** currently spec'd as "Gen<X>" qualifiedName "p.Gen" ** currently spec'd as "p.Gen<X>" isClass isGenericType isTopLevel ITypeBinding for declaration of Gen.Inn name "Inn" qualifiedName "p.Gen.Inn" ** currently spec'd as "p.Gen<X>.Inn" isClass isMember isNested ITypeBinding for variable v1 name "Gen<String>" qualifiedName "p.Gen<java.lang.String>" isClass isParameterizedType isTopLevel ITypeBinding for variable v2 name "Inn" qualifiedName "p.Gen<java.lang.String>.Inn" isClass isMember isNested ITypeBinding for variable v3 name "Gen" qualifiedName "p.Gen" isClass isRawType isTopLevel ITypeBinding for variable v4 name "Gen.Inn" qualifiedName "p.Gen.Inn" isClass isMember isNested Martin, Would these names be useful?
Yes, that looks very good. To avoid the type variable names in the generic type names is a good change. The most common use of the qualified name was to serve as a unique type identifier that could be used amongst other things to brigde between the Java Model IType and the AST TypeDeclaration. That is currently broken with the variable names in type names so that's why I support the suggested change. (It has to be noted that the bridging problem is now partly solved with the new API IBinding.getJavaElement)
I've revised the specs for ITypeBinding.getName() and getQualifiedName(). Olivier, over to you
Jim, Are you sure that the name for v4 is "Gen.Inn". I would say it should be "Inn" according to the spec of getName().
Jim, According to your answer, I will reopen this PR or consider it as fixed. Fixed and released in HEAD. Regression test added.
My mistake. The name of v4 should be "Inn", not "Gen.Inn".
I've also corrected the specs for both methods re: wildcard types to mention that "super" can appear as well as "extends" (and that there are single spaces before and after the keyword).
Regression test is ASTConverter15Test#test0063. Verified (in I20041214-2000) that this test ensures that the qualified name of a parameterized type binding with wild card argument is correct.
