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

[Alex Buckley]

"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.

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