interactions between type annotations and language model APIs.

[Joe Darcy]

Hi Bruce,

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 
AnnotationMirror> annotations)

<T extends TypeMirror> T withAnnotations(T typeMirror, 
AnnotatedConstruct annotationHost)

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.

-Joe