[Checkers] AnnotatedTypeMirror is not sufficiently unique
Mahmood Ali
mahmood at MIT.EDU
Fri Oct 3 11:17:57 EDT 2008
Greetings,
Mike is correct in his analysis in the earlier email.
> The reason I assumed that AnnotatedTypeMirror was to be unique for
> each Element is that they have a getElement method. I'm at a loss
> why there is this method at all if the AnnotatedTypeMirror is just
> to wrap the TypeMirror and disregard the element property which may
> be different for "equal" types.
The stored element is not meant to be part of the identity of the type.
Currently, there methods to go from Tree and Element (and visa versa)
and from both to type. We found it useful to have a method to go from
a type to the element generating it, particularly for method and type
parameter types. However, getElement() is intentionally left
undocumented as to when the element is available to discourage using
it outside the framework until we come up with better plan.
> If I can get a unique AnnotatedTypeMirror for a Tree or Element,
> then I can create an identity map that maps those to the method
> receiver in the annotateImplicit methods. This allows me to latter
> look them up in cases where I only have the AnnotatedTypeMirror (as
> with the isSubtype method in the BaseTypeChecker).
I would approach this issue a bit differently. In the Framework, we
would always represent the context with annotations on the type, so
other methods are decoupled from the context. I assume that you may
able to do this too.
In IGJ for instance, given a field annotated with '@I' and a use
within a method, '@I' gets resolved to the enclosing method receiver.
This is done by annotateImplicit in IGJ. Thus, isSubtype never needs
to check the context of the field access, as it was abstracted away by
the inserted annotation. A similar approach is used for Flow, as the
context gets abstracted away with Flow adding the appropriate
annotations.
Hope this helps,
Mahmood
More information about the checkers
mailing list