interactions between type annotations and language model APIs.

[Bruce Chapman]

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>?
>
>>
>> withAnnotations(typeof(List<String>), typeof(@Nullable String)> would 
>> return typeof(List<@Nullable String>?
>
> I intended this to return
>
> @Nullable List<String>
So how would we construct (for example) List<@Nullable String>  if 
Types.getDeclaredType() stripped @Nullable off String, and there is no 
deep back substitution?

And given that deep back substitution is also problematic, could it work 
if we had an explicit function to (possibly recursively) strip all 
annotations from a type, or strip specified (with a List<Declaredtype>) 
annotations from a type, but did not strip in Types' existing methods? 
We might also need a stripAnnotationsExcept(TypeMirror t, 
List<DeclaredType> retainedAnnotationTypes) to provide for all 
possibilities. Along with something to add annotations, I think that 
would provide a full set of construction techniques. Users would still 
need to write their own versions of Types.isXXX() if the annotations 
were significant for their use case.

Are Michael Ernst and JSR308 E.G.  across this thread?

Bruce


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


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