Ok. So, this means that we should have AnnotationType
as a subclass of
FAMIXType.
yep
> For some reason, Java does considers
annotationType attributes as
> methods:
> Maybe this is because annotations are similar to
interfaces and
> interfaces don't have attribute?
> To me they look more like attributes,
syntactically and semantically
This is odd, indeed. But, I am not sure I understand
the implication.
Would it not be enough if we make AnnotationTypeAttribute a subclass
of FAMIX.StructuralEntity?
Yes it would. For the current use of AnnotationTypeAttribute, it actually does not really
matters, where they are.
However, agreeing that AnnotationType will be a Type, it would make sense to consider that
AnnotationTypeAttribute are attributes (i.e. FamixAttribute) of this new Type.
So this would advocate for AnnotationTypeAttribute being a special case of
FamixAttribute.
But, this is not a very strong argument, in fine, the only difference between a
FamixAttribute and a StrucuralEntity is 'parentType' which is just a renaming of
'belongsTo'. So both have the same information.
nicolas
PS: Any idea why verveineJ tests on Hudson play the yoyo? I don't remember commiting
anything fundamental since build #16. So why is the number of tests dropping to 0 now and
then?
Also, 15 of the 17 faulty tests in build #22 (and before) are due to a lacking
'getBelongsTo()' method in EnumValue:
---
java.lang.UnsupportedOperationException: NamedEntity.getBelongsTo() Not implemented in
this class, use the proper subclass (fr.inria.verveine.core.gen.famix.EnumValue)
---
Something that was correct last week. So either Hudson does not have the corrected
fr.inria.verveine.core.gen.famix code, or it is not generating the famix.jar file or it is
not using it it when it runs verveine.
Could you have a look at that?
tx