interactions between type annotations and language model APIs.

[Joe Darcy]

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.

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

I intended this to return

@Nullable List<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.

I don't see you good way to approach that problem. Stripping the 
annotations and allowing them to be added, gives interested parties full 
control while being a tractable API.

Thanks,

-Joe

>
> 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
>