[JSR308] Creating new annotated types.
mahmood at MIT.EDU
Thu Nov 13 16:02:50 EST 2008
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
> 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.
More information about the JSR308