Updated JEP: nestmates

[David Holmes]

On 14/04/2017 8:05 AM, forax at univ-mlv.fr wrote:
> It seems we are all on the same page but some of us talk about the spec and other about the implementation.

Not sure which of "us" you are referring to for what discussion. :)

I was trying to stick with the spec but the definition of the attributes 
and when they are allowed and not allowed, is part of the spec.

David

> From the spec point of view, i agree with Brian,
> "Every class belongs to exactly one nest",
> - if there is a MemberOfNest attribute, it defines the nest,
> - if there is a NestMembers attribute, it defines the nest-top,
> - if there is no attribute, it defines its own nest.
> and "Every nest has a canonical, consistent nest-top".
>
> Rémi
>
> ----- Mail original -----
>> De: "David Holmes" <david.holmes at oracle.com>
>> À: "Brian Goetz" <brian.goetz at oracle.com>, forax at univ-mlv.fr
>> Cc: "John Rose" <john.r.rose at oracle.com>, valhalla-dev at openjdk.java.net
>> Envoyé: Jeudi 13 Avril 2017 23:57:59
>> Objet: Re: Updated JEP: nestmates
>
>> On 14/04/2017 7:50 AM, Brian Goetz wrote:
>>>> The second part most certainly is necessary as a nest-top does not
>>>> itself have a nest-top!
>>>
>>> I would think we'd consider a nest-top as its own nest-top. That way,
>>> every nest has a top, which acts as a canonical element for that nest.
>>
>> From an implementation perspective certainly that simplifies
>> nest-membership checks. but do you want that in the spec? Do you want
>> javac to generate a self-referential MemberOfNest attribute? If you want
>> this then the definitions need a rewrite. This is not where we are today.
>>
>>>> It is not an optimization! You are either a nest-top (and so have a
>>>> NestMembers attribute) or you are a nested type and so have a
>>>> MemberOfNest attribute. (Of course you can be neither.)
>>>
>>> Similarly, I'd think that every class that has neither a NestMembers or
>>> MemberOfNest attribute constitutes a nest of one.
>>
>> Sure logically you can consider it that way. Not sure it has any real
>> affect on anything.
>>
>>> Taken together, now:
>>>  - Every class belongs to exactly one nest;
>>>  - Every nest has a canonical, consistent nest-top (every member of the
>>> nest agrees on the nest top)
>>
>> Yes.
>>
>>> This will become relevant when we extend this to support
>>> Lookup.defineClass with a private lookup, which has the effect of
>>> injecting a new class into an existing nest.  If every class is already
>>> in a nest, this injection is simplified.
>>
>> I don't really see how it makes a difference, but you presumably have
>> something in mind here.
>>
>> Thanks,
>> David