Updated JEP: nestmates

[David Holmes]

On 14/04/2017 8:12 AM, Brian Goetz wrote:
> I was trying to make the model simpler to reason about.  My mathematical
> model is that nests form a partition over classes, meaning:
>  - every class belongs to a nest
>  - no two nests have any members in common
>  - every nest has a canonical member
>
> We can't rely on javac (or other compilers) to always generate "nest of
> one" attributes, so the VM would have to, on seeing a class with no nest
> attributes, set "nestTop = me".  But I think that would be the only
> change in the implementation?  And then nestTop(C) becomes a total
> function, which simplifies things.

The implementation already sets nestTop='me'. But it never expects to 
see a MemberOfNest attribute already set to 'me'. It complicates things 
if the specification both allows no nestmate attributes and allows 
MemberOfNest='me' (at parsing time there is not yet a 'me' so this would 
based on the name in the constant pool.)

David

> I'm fine if the spec says this; in fact, I like it.
>
> On 4/13/2017 5:57 PM, David Holmes wrote:
>> 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
>>
>