impl for annotated types

[Werner Dietl]

Hi Jon, Joel, all,

there are currently 5 places where AnnotatedTypes are instantiated, so
the required changes should be quite encapsulated.

cu, WMD.

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:
>>> Werner,
>>>
>>> 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.
>
> cheers
> /Joel



-- 
http://www.google.com/profiles/wdietl