[type-annos-observers] Comments on the Nov 7 specification

[Srikanth S Adayapalam]

> From: Alex Buckley <alex.buckley at oracle.com>
> Sent by: type-annotations-spec-experts-bounces at openjdk.java.net
> 
> "main type" is not a JLS term and can be interpreted in more than one 
> way. Same goes for "scoping information". There is clearly more than one 

> perspective here. I am not arguing for one approach or another (though I 

> do have a favorite); I am arguing for absolute clarity. Let's wait for 
> Srikanth's comments.

Since there was an earlier question about how other tools that build AST
build their ASTs: Eclipse compiler builds two altogether different ASTs: 
the so called
compiler AST and the DOM/AST. Class file generation happens from the 
former
while the latter is used by clients that want structural (as opposed to 
textual)
modifications to the program.

The type Outer.Middle.Inner (earlier mail had the order wrong as 
Outer.Inner.Middle)
gets represented in the compiler AST as a single node 
QualifiedTypeReference with
a char[][] representing the tokens that make up the types.

Annotations are similarly represented as Annotation [][].

On the DOM/AST side, we do represent the qualified type as a tree with the 
each
inner level containing the qualifying type, but this AST is not used for 
class file
generation.

I do see the point about signature decoding ASM, but bottomline: I don't 
see an overwhelming 
preference for one approach vs other from our side.

Srikanth.


> 
> Alex
> 
> On 11/27/2012 5:48 AM, Michael Ernst wrote:
> > Eric-
> >
> > Thanks for the followup; I appreciate it.
> >
> > We are all agreed on "outside to inside" for generics; it is 
definitely
> > superior.
> >
> > Your original message and my request for clarification was about 
nested
> > types.  "Outside to inside" is ambiguous for nested types, so I think 
we
> > should avoid that terminology.  For nested types, it seems there is 
merit
> > to having paths start at the main type, then proceeding to scoping
> > information -- which would be similar to the preferred "outside to 
inside"
> > approach that is used for generics.
> >
> >            Thanks,
> >
> >           -Mike
> >
> >
> >> Subject: Re: [type-annos-observers] Comments on the Nov 7 
specification
> >> From: Eric Bruneton <ebruneton at free.fr>
> >> To: type-annotations-spec-comments at openjdk.java.net
> >> Date: Sat, 24 Nov 2012 17:28:47 +0100
> >>
> >> 20/11/2012 21:37, Michael Ernst wrote:
> >>> Eric Bruneton said:
> >>>
> >>>>   From an ASM point of view,
> >>>> ...
> >>>> The important
> >>>> point is that all paths should be "from outside to inside" 
> (e.g. for nested
> >>>> types, the path should go from outer to inner, not the other 
> way around as
> >>>> proposed in the Nov 7 specification).
> >>>
> >>> Eric, I'm willing to make this change, but I would like to be able 
to give
> >>> a more specific justification for the design choice.  Can you 
explain the
> >>> rationale, or what difference it makes to ASM?  Is the reason that 
the
> >>> identifiers appear left-to-right in the class file and you want to 
process
> >>> them in that order, or is it something else?
> >>
> >> Right, it's basically that. For instance, consider the problem of
> >> extracting the part of a type signature in the class file format
> >> (e.g. Ljava.util.Map<
> +Ljava.lang.String;Ljava.util.List<Ljava.lang.Object;>;>;)
> >> that corresponds to a given type_path. With 'outside to inside' 
paths, this
> >> can be done with a simple recursive function, like
> >> extract(signature,path)
> >> - if empty path return signature
> >> - otherwise parse the first signature element from the left, 
> check conformity
> >>    with first path element, and call recursively with tail of 
signature and
> >>    tail of path.
> >>
> >> With 'inside to outside' paths, you have to parse the three inner 
types in
> >> the signature to realize that
> >> "inner_path{inner_path{inner_path{empty_path}}}", for instance, was 
in fact
> >> the first parsed type (then you either have to save state during 
parsing,
> >> or do another parsing pass).
> >>
> >> I'm not sure I'm clear, but I hope you get the idea.
> >>
> >> Eric
>