mahmood at MIT.EDU
Mon Aug 18 22:59:03 EDT 2008
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
More information about the checkers