interactions between type annotations and language model APIs.
joe.darcy at oracle.com
Mon May 12 21:39:26 UTC 2014
On 5/12/2014 2:17 AM, Bruce Chapman wrote:
> On 12/05/2014 4:23 a.m., Joe Darcy wrote:
>> Hi Bruce,
>> On 5/11/2014 1:35 AM, Bruce Chapman wrote:
>>> I think you are on the right track here. Types' methods would
>>> probably strip type annotations, but provide tools for the user to
>>> reinsert them when the user knows that is appropriate and valuable
>>> given the semantics of the annotation and what the code is trying to
>>> do. I am presuming Joe's second method would in some way back
>>> substitute an annotated type for an (possibly) unannotated type
>>> within the typeMirror argument?
>> The intention is the second method was that the returned value would
>> be a wrapper around the first argument that had the annotations of
>> the second argument.
> So wouldn't the second argument be better as List<AnnotationMirror>?
To flesh out the semantics of the two methods I proposed:
<T extends TypeMirror> T withAnnotations(T typeMirror, List<? extends
<T extends TypeMirror> T withAnnotations(T typeMirror,
Both methods would return a wrapper object around the first argument.
The second argument would supply the annotations for the wrapper object.
In the first method, the annotation mirrors would be used; in the second
method, the wrapper would use the annotations on the second argument
(perhaps after some applicability checks). The second method has
intended to support use cases like "this type should be regarded as
having the same annotations as this object, perhaps some supertype, etc."
At least with this API sketch, this is a low-level API that would have
the expressibility to create any annotation structure. However, it might
not be very convenient to use for complicated transformations.
More information about the compiler-dev