Community
Participate
Working Groups
200411022000 The AST for a source reference List<String> looks like this: ParameterizedType ("List<String>") - typeBinding: List<String> type: + SimpleType ("List") - typeBinding: *null* name: + SimpleName ("List") - typeBinding: List<String> typeArguments: + SimpleType ("String") - typeBinding: String name: + SimpleName ("String") - typeBinding: String I would expect that the SimpleType ("List") also has a typeBinding List<String>.
I could understand the binding for the SimpleType ("List") in the Parameterized Type would be List, but certainly not List<String>. The corresponding simple name should also be List and not List<String>. Do you agree?
Not quite. An analogy would be with method bindings: List<String> ls= ...; List<Integer> li= ...; ls.add(""); //binding of SimpleName 'add': List<String>.add(String) li.add(new Integer(1));//binding of SimpleName 'add': List<Integer>.add(Integer) I discussed this with Dirk and Martin, and we feel like it would be more convenient if 'List' in 'List<String>' would also have the most discriminating binding List<String> (although we cannot "prove" why the "erasure / declaration / generic type" List<E> would definitely be wrong). In theory, the bindings for 'add' above could also be List<E>.add(E), but that's also not the case (and we think it's fine as it is now). The binding certainly cannot be raw type List, since no raw type is involved.
For me, it is completely inconsistent for a simple type to end up with a generic binding. I believe that the fact that the name inside the simple type resolves to a generic type binding is a bug.
I discussed with Jim and we believe that the right answer for the binding of the simple type List is the erasure of List, so List<E>. I don't think we should compare it to the method case that is really ugly. I wish we didn't return a binding for the name that represent the method selector, because the name itself means nothing without the parameters and the return type. So I would vote to return the erasure and the inner name would resolves to the erasure as well. Any comment?
I agree that the method and the type cases are not the same. The method invocations bind to different methods, and the method names' bindings reflect that. In the List<String> case, I think we could live with getting the generic List<E> for the SimpleName "List". This would also be in line with arrays like String[], where the SimpleName "String" also has type binding String. On the other hand, for a raw reference to "List", the bindings of the SimpleType and the SimpleName would then be different. That would also seem strange to me. Martin & Dirk?
In my opinion List should have the parametrized binding List<String> with the reason that parametrized bindings are for references but generic bindings (List<E>) for declarations. So it wouldn't it be weird to suddendly get a 'declaration' binding in a reference? If not, things get tricky for clients holding a simple type node as they would first have to check the parent to see if it's a parametrized type and to get the binding from there. Also note that it's easy to get the generic type from a parametrized type binding, but the other way around is (currently) not possible .
Ok. I'll do it according to comment 6. Jim, is this fine for you? I know we talked about returning the erasure, but this would mean that it corresponds to the declaration, not the call.
I concur.
Fixed and released in HEAD. Regression test added in ASTConverter15Test.test0073
Verified (in I200412140800) that the test ensures that the binding of the return type, the binding of the simple name, and the binding of the erasure are all the same (and non null).
