[JSR308] Creating new annotated types.

[Mahmood Ali]

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