[JSR308] Others possible syntaxes for type annotations

Igor Peshansky igorp at us.ibm.com
Sun May 20 23:30:22 EDT 2007


Eugene Kuleshov wrote on 05/17/2007 04:46:22 PM:

>   Interesting. It seems like there is no ambiguity, but such syntax look 

> confusing. Mostly because of "," or ";" used to separate annotations. 
> But the idea is still worth investigation.
> 
>   I've tried to play with the following grammar change and like it more 
> when type annotations are put before type arguments or parameters. There 

> is still no ambiguity and optional annotations are reasonably separate 
> from other type arguments. The only concern here is that such syntax is 
> more verbose then syntax proposed by the currently implemented 
prototype.
> 
> TypeArguments:
>         <[Annotations] TypeArgument {, TypeArgument} >
> TypeParameters:
>         <[Annotations] TypeParameter {, TypeParameter} >

Sorry if I'm jumping in late on this discussion.

I always understood that the type parameters of a generic type are part
of the type (i.e., List<Integer> is a different type from List<String>,
rather than them both being constrained Lists).  So it seems that whatever
annotations you want to put on the type should follow the type parameters,
otherwise they look like they're only constraining the base type (in my
example, List).

Also, Maxim is right -- the annotations that precede type parameters with
no separator do look like they are annotating the parameters, not the base
type.
        Igor

>   Here is how examples from JSR-308 document would look in such syntax:
> 
>     Map<String<@NonNull>, List<@NonEmpty Document<@Readonly>>> files;
> 
>     o.<String<@NonNull>>m("...");
> 
>     class Folder<F extends File<@Existing>> { ... }
>     Collection<? super File<@Existing>>
> 
>     class UnmodifiableList<T> implements List<@Readonly T<@Readonly>> { 
> ... }
> 
>     void monitorTemperature() throws TemperatureException<@Critical> { 
... }
> 
>     myString = (String<@NonNull>) myObject;
> 
>     boolean isNonNull = myString instanceof String<@NonNull>;
> 
>     new List<@NonEmpty @Readonly String>(myNonEmptyStringSet)
> 
>     new <@Interned String> MyObject()
> 
>     public <@Readonly> int size() { ... }  // method receiver
> 
>     Class<String<@NonNull>> c = String<@NonNull>.class;
> 
>   regards,
>   Eugene
> 
> 
> Maxim Kizub wrote:
> > I think, grammar changes may be specified as:
> >
> > TypeArguments:
> >       < TypeOrAnnotArgument {, TypeOrAnnotArgument} >
> >
> > TypeOrAnnotArgument :
> >       [TypeArgument | Annotation]
> >
> > or as
> >
> > TypeArguments:
> >       < ? [TypeArgument {, TypeArgument}] ?[; Annotations] >
> >
> > I'm not familiar with this parser grammar notation, so I don't know 
> > how to express that annotations go after type parameters.
> > For JavaCC grammar would be:
> >
> > TypeArguments() : {}
> > {
> > "<"
> >   TypeArgument() ( "," TypeArgument())* ( "," Annotation() )*
> > |   Annotation() ( "," Annotation() )*
> > ">"
> > }
> >
> > or
> >
> > TypeArguments() : {}
> > {
> > "<"
> >   TypeArgument() ( "," TypeArgument())* [ ";" Annotations() ]
> > |   [ ";" ] Annotations()
> > ">"
> > }
> >
> > JavaCC grammar needs no lookahead, since annotations are clearly 
> > distinct from type parameters (because they start with @ token)
> >
> > Map<Foo<Boo>, Map<String, Boo>> can be annotated as
> >
> > Map<Foo<Boo, @BooAnnot>, Map<String, Boo, @MapInnerAnnot>, @MapAnnot>
> >
> > or using semicolon as the separator
> >
> > Map<Foo<Boo; @FooAnnot>, Map<String, Boo; @MapInnerAnnot>; @MapAnnot>
> >
> > or annotating everything will be
> >
> > Map<Foo<Boo<@BooAnnot>; @FooBooAnnot>, Map<String<@StringAnnot>, 
> > Boo<@BooAnnot>; @MapStrBooAnnot>; @MapFooBooMapStrBooAnnot>

-- 
Igor Peshansky  (note the spelling change!)
IBM T.J. Watson Research Center
XJ: No More Pain for XML's Gain (http://www.research.ibm.com/xj/)
X10: Parallel Productivity and Performance (http://x10.sf.net/)



More information about the JSR308 mailing list