Updated JEP: nestmates

[Brian Goetz]

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.

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
>