Rethinking TypeAnnotation vs Annotation
wdietl at gmail.com
Thu Feb 6 13:48:41 PST 2014
an alternative would be to keep Compound only while it is unclear
whether an annotation is a type or declaration annotation and
introduce a new DeclarationCompound class that can be used when only
declaration annotations are expected.
Why not have the type system help us keep things straight?
On Thu, Feb 6, 2014 at 4:26 PM, Joel Borggrén-Franck
<joel.franck at oracle.com> wrote:
> Hi Eric,
> On 06 Feb 2014, at 20:59, Eric McCorkle <eric.mccorkle at oracle.com> wrote:
>> In the process of working on the next roadmap step for type annotations,
>> I've realized something.
>> The current implementation, and I think most of everyone's thinking on
>> annotations treats type annotations as a special case of regular
>> annotations. Indeed, this is sort of the intuitive first thought.
>> But looking at the actual implementation details, I think the reverse is
>> actually true. Any given annotation is potentially a type annotation,
>> especially earlier in the javac pipeline (where I'm presently generating
>> TypeAnnotationPositions in my new patch). So, on the implementation
>> front, it makes perfect sense to do things like store
>> TypeAnnotationPositions in Attribute.Compound, as opposed to
>> I think this would also go a long way towards creating the single
>> codepath for attaching annotations that I want to create.
> I have never been a big fan of the TypeCompound class at all. Also reading some more in 9.7.4 it looks like annotation can be both a type anno and a declaration anno. So, from my perspective, dumping TypeCompound and moving its data up to Compound seems like something to try out.
More information about the compiler-dev