Community
Participate
Working Groups
In order to better support the uniform treatment of (annotation/enum) type declarations, several methods should be pulled up to AbstractTypeDeclaration: - getFields, getMethods, getTypes - get/set SuperclassType - superInterfaceTypes, typeParameters Moreover, AbstractTypeDeclaration could offer methods to get the appropriate structural property descriptors of the subclass (e.g. the BODY_DECLARATIONS_PROPERTY)
The problem is that these node types are quite dissimilar: superInterfaceTypes() - annotation types do not have these get/setSuperclassType() - annotation types and enum do not have these typeParameters() - annotation types and enum do not have these getField() - enum types have enum constants, but they are not field declarations getMethod() - annotation types have AnnotationTypeMemberDeclarations, which are not methods In short, pulling this functionality up to AbstractTypeDeclaration would make the API more irregular.
I agree for getMethods() and getFields(). But the fact that abstract type declarations do not necessarily offer superclass types/superinterface types and type parameters does not contradict the need for uniform treatment of type declarations. More important: There is currently no way to transparently get structural property descriptors based on an object of type AbstractTypeDeclaration (e.g. during a list rewrite). In order to handle e.g. body declarations one has to differentiate between three different types doing type tests, which is somehow cumbersome. Methods as 'ChildListPropertyDescriptor AbstractTypeDeclaration#getBodyDeclarationsDescriptor()' would be helpful in these cases.
On your first point, the nodes do not have a uniform structure. Adding superInterfaceTypes, etc. to annotations might make things more uniform for some clients, but not for all (e.g., these unused properties need to be ignored during serialization). So I'm reluctant to add unused properties unless there would be a significant advantage from doing so. On your second point, we would need to add the following reified property methods to the abstract node classes to match what these abstract classes current support in the non-reified forms. Annotation public ChildPropertyDescriptor getTypeNameProperty(); AbstractTypeDeclaration public ChildListPropertyDescriptor getBodyDeclarationsProperty(); public ChildPropertyDescriptor getNameProperty(); BodyDeclaration public SimplePropertyDescriptor getModifiersProperty(); public ChildListPropertyDescriptor getModifiers2Property(); public ChildPropertyDescriptor getJavadocProperty(); VariableDeclaration public SimplePropertyDescriptor getExtraDimensionsProperty(); public ChildPropertyDescriptor getInitializerProperty(); public ChildPropertyDescriptor getNameProperty(); These changes would make the API more uniform. We can add them if you think they will be helpful.
ad 1) I can see your point. However, the superclass/supertype, superInterfacetypes, and typeParameters properties are optional anyway. If there is a way to have these methods in AbstractTypeDeclaration returning null or an empty list, resp., without actually introducing unused properties in the subtypes, the implementation of these methods should not break existing clients. From the JDT UI side (in particular refactoring), such methods would be very helpful (e.g transparent handling of generic types, move refactorings, etc.). Otherwise, many type tests have to be performed. If there is any chance to implement this without breaking too many internal clients in JDT Core, it would be a great help. ad 2) This is exactly what we need! We would be glad if you can add them.
re: 1) I don't see a good way to do this. Although the property values are optional, we would otherwise need to treat them as real properties whose value happens to be ignored by serialization (like the return type of a method declaration when used for a constructor). re: 2) I will add these methods. On BodyDeclaration, rather than introduce a new method which would be deprecated in 3.1 as well, I would only handle the JLS3 properties: public ChildListPropertyDescriptor getModifiersProperty(); // for JLS3 property public ChildPropertyDescriptor getJavadocProperty();
Agreed.
The new methods are included in v_521. (I was late in updating the build notes.)
Verified in 200412140800
