[Checkers] QualifierHierarchy

[Mahmood Ali]

Greetings Artemus,

Thanks for continue the discussion.

> Such implementation for subtyping would see if all elements on the  
> right hand side (the sub types) were a sub type of at least one  
> element on the left hand side (the super types), and any elements on  
> the left hand side that did not match up with at least one element  
> on the right hand side would be tested to check if the root  
> annotation were a sub type of it.
> Instead of the current implementation of just checking if there is  
> one match.
Very true.  The current implementation decision is primarily  
historical at this point.

> I guess most situations where you might want the type data, you  
> could add such information in the annotation implicit method, such  
> as @Strictfp that would indicate that the variable was formed though  
> strictfp operations. In that case instances of int and long could  
> automatically be annotated as being @Strictfp.

Umm.. I am not quite sure if I follow this example either.  The manual  
section 2.6 'The effective qualifier on a type' describes how we  
address implicit and default types for expressions.  You need the  
actual type (e.g. int, long) to know whether to add @Strictfp or not,  
but you only need the annotation when checking sub-typing rules.

However, I do realize that QualifierHierarchy should only be used by  
TypeHierarchy.  TypeHierarchy is the representation/interface needed  
for the rest of the checker, while QualifierHierarchy is an  
engineering representation to abstract some code out of the  
TypeHierarchy to enable reuse.  The current framework basically  
prevents you from having a checker with TypeHierarchy without  
QualifierHierarchy, which may be needed for some hierarchies.   
Personally, I do see the engineering aspect of it; however, I fail to  
come up with a case where QualifierHierarchy representation is not  
needed.

Regards,
Mahmood