impl for annotated types
wdietl at gmail.com
Thu Feb 14 10:23:18 PST 2013
Hi Jon, Joel, all,
there are currently 5 places where AnnotatedTypes are instantiated, so
the required changes should be quite encapsulated.
On Thu, Feb 14, 2013 at 9:58 AM, Joel Borggrén-Franck
<joel.franck at oracle.com> wrote:
> Hi all,
> On Feb 14, 2013, at 6:48 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
>> On 02/14/2013 09:43 AM, Jonathan Gibbons wrote:
>>> How well encapsulated is the code to create instances of javac.code.Type that have annotations? For example, is it always encapsulated within a method such as Type.createAnnotatedType, for use like
>>> Type annoType = type.createAnnotatedType(annos);
> The current implementation is not that well encapsulated but I improve on this in my patch to add javax.lang.model. That can of course be refactored out of the model work and applied separately.
>>> As a follow-up, think of this as a thinking-aloud hypothetical question....
>>> Previously, we've considered delegation and subtyping as a way of representing annotated types. What if we gave up on the "minimize space" requirement and added a List<Attribute.TypeCompound> into each Type? How easy would that be?
>> Assuming we have to go for some combination of ugly methods and ugly types for javax.lang.model.type, how well would such a proposal fit in with the proposed ugly types?
> I think this would be quite easy and should also work well with the model implementation.
> In some ways this makes sense because we can then address the space issues with all kinds of annotations, IMHO they are related issues.
More information about the type-annotations-dev