interactions between type annotations and language model APIs.

[Bruce Chapman]

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?

withAnnotations(typeof(List<String>), typeof(@Nullable String)> would 
return typeof(List<@Nullable String>?

if so, what happens when the second argument appears more than once in 
the first argument? e.g. Map<String, List<String>?

Despite these difficulties, I still think stripping then tools to 
reinsert the type annotations is what would be most useful.

The alternative would be some way to tell types' method what should happen.

Bruce


On 10/05/2014 9:36 a.m., Alex Buckley wrote:
> Joe,
>
> On 5/9/2014 8:24 AM, Joe Darcy wrote:
>> My first reaction here is that these methods should by default ignore
>> annotations and we should add another utility method or two like:
>>
>> <T extends TypeMirror> T withAnnotations(T typeMirror, List<? extends
>> AnnotationMirror> annotations)
>>
>> <T extends TypeMirror> T withAnnotations(T typeMirror,
>> AnnotatedConstruct annotationHost)
>>
>> to allow the annotations savvy user to perform whatever annotation
>> passing along or computation is appropriate for the problem domain.
>
> In other words, specify in javax.lang.model.util.Types that it is 
> unspecified as to the presence of type annotations in a TypeMirror 
> object returned by a Types' method ? And also, specify builder methods 
> that decorate an existing TypeMirror object with type annotations ?
>
> This approach sidesteps the complexities (alluded to in my prior mail) 
> of trying to enrich certain methods' results with type annotations.
>
> This approach also exposes that "there's more than one way to do it", 
> so we should not rush into decisions that ultimately will be part of 
> JSR 269's next Maintenance Review. Do you keep a to-do list for 269 
> somewhere?
>
> Alex
>


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com