[JSR308] Creating new annotated types.

Mahmood Ali mahmood at MIT.EDU
Thu Nov 13 16:02:50 EST 2008


Greetings Niko,

Thanks for your input and I appreciate your comments.

> Well, one example that comes to mind is mapping the annotations on a  
> type that you receive as input.  Right now, the only way I know of  
> to do that is destructively (i.e., mutate the annotated type mirror  
> in place).  You can use getCopy() to make a shallow copy, but when  
> you have a compound type such as a DeclaredType or an ExecutableType  
> that does not allow you to map annotations on the subtypes, such as  
> type arguments.  A deep clone operation solves this problem.
AnnotatedTypes.deepCopy() returns a deep clone of the annotated type.   
I don't know how it is different from AnnotatedTypeCloner.

Besides preferring mutability, what are the motivations/rationale of  
wanting deep cloning.  Your insight would help us documenting aliasing  
better.

> I run into this in my code fairly frequently, as my annotations are  
> more like type arguments than the binary present/absent annotations  
> that the checkers framework is designed for.  In other words, types  
> in my system have exactly one annotation, which is deserialized into  
> a structured set of region and effect parameters.  I sometimes need  
> to apply mappings to these annotations which can affect not only the  
> type at hand but also its type arguments.
>
> One example where this comes up is in the isSubtype() function.  In  
> this case, I have two type mirrors as input and I would like to do  
> some implicit inference in the future that might require remapping  
> the annotations as part of the subtype test.  Right now I would  
> simply not be able to do this.
I apologize but I don't quite understand the context or what your  
checker checks for.

> Off hand, I can't think of a specific case where the added  
> flexibility I put into the AnnotatedTypeCloner class is necessary.   
> However, I also don't see how it's dangerous.  As I said, I'd be  
> more worried about having insufficient flexibility than too much.
We will be happy to add such flexibility in the system, once see a case.

Whenever the framework is limiting you significantly in cases you care  
about, then we can correspond to make a good solution and incorporate  
it to the framework.  If you change the framework for something, you  
can send your patches as well.

Regards,
Mahmood




More information about the JSR308 mailing list