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

[Alex Buckley]

Srikanth, thanks for this information.

Mike, here is my view: I think nested types should be represented "left 
to right", so that @A, @B, and @C in:

   @A Outer. @B Middle. @C Inner

are located with these type_path_entry arrays:

   @A: -
   @B: 1(0)
   @C: 1(0), 1(0)

I recognize this is not congruent with javac's AST, but I think it is 
the right all-round representation.

Alex

On 11/29/2012 10:03 PM, Srikanth S Adayapalam wrote:
>  > 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
>  >