[Checkers] QualifierHierarchy

[Artemus Harper]

> We chose to target this common case first, to keep the abstraction
> manageable (for users and for implementers) in the common case.  We
> recognize that there are valid reasons to build more complex type systems,
> but don't have experience with enough of them to build that support in.
> Your experience might help to inform an eventual design.
>
 I'll accept this point. I do however believe that the default
implementation determining the relationship of multiple annotations would
work in such a way that it is possible to combine 2 or more annotation
checkers into a single checker. 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.


> I'm a touch confused, because this this isn't an example of the first
> phrase of the sentence.  "UIResource.class" is an argument to the
> @Constrained annotation, not the the the annotations are on.  Did you mean
> for your example to be "@Constrained UIResource", or were you making a
> separate point?

You are right, not a good example. 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.



-- 
Artemus Harper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.csail.mit.edu/mailman/private/checkers/attachments/20080818/54597765/attachment.htm