Updated JEP: nestmates

[forax at univ-mlv.fr]

----- Mail original -----
> De: "David Holmes" <david.holmes 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 13:33:56
> Objet: Re: Updated JEP: nestmates

> On 13/04/2017 8:51 PM, forax at univ-mlv.fr wrote:
>> ----- Mail original -----
>>> De: "David Holmes" <david.holmes at oracle.com>
>>> À: "John Rose" <john.r.rose at oracle.com>, "Rémi Forax" <forax at univ-mlv.fr>
>>> Cc: valhalla-dev at openjdk.java.net
>>> Envoyé: Jeudi 13 Avril 2017 02:36:59
>>> Objet: Re: Updated JEP: nestmates
>>
>>> On 13/04/2017 9:16 AM, John Rose wrote:
>>>> On Apr 12, 2017, at 3:00 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>>>>>
>>>>> This JEP is not about the JVM providing a way to add a new member to the nest,
>>>>> so if a language (stupidly you may say) allow to dynamically add a new member to
>>>>> a nest, the runtime of that language still needs lookup.in().
>>>>
>>>> Good point, thanks.  I removed that bullet item.  (Also tidied a few other
>>>> bits.)  — John
>>>
>>> If lookup() now provides access to nest members (which it does) then I
>>> would expect it to provide access to the newly added member as well.
>>
>> Lookup will be upgraded to provides 'nest access' to members defined as
>> nestmates.
>> But as specified by this JEP, the nestmate relationship has to be set up before
>> classloading time:
>> - once a nest-top is loaded you can not add another nest member,
>> - once a type is loaded, it can not be part of a nest afterward.
>>
>> So nestmates is not a dynamic relationship.
>>
>> If i want to have dynamic nests at runtime, i can not use nestmates,
>> but i can *simulate* them, by creating a Lookup on a nest-top (or any other nest
>> members) and using Lookup.in() to see it as a Lookup of a nest member.
>> So Lookup.in() do not provide exactly the same feature as nestmates, thus it
>> should not be deprecated/demoted.
> 
> Sorry there are too many missing pieces here for me. What does a
> "simulated" nest-mate even mean? What did you introduce, where and how?
> And what access are you expecting to have to what, and how is that
> access being allowed ???

Imagine a scripting language that compiles several classes as part of the same script,
the semantics of the language allow code of the same script to see private members of the classes if there are in the same script.
That scripting language can leverage the nestmate attributes for that.

Now imagine that this scripting language allows to dynamically add some newly created classes as if they were part of an existing script, here you can not use the nestmate attributes for that because you can not re-open a nest-top at runtime to add newly created types as part of a NestMembers attribute. For that, you can use Lookup.in().

My first email in that thread was about saying to John that nestmate attributes are a compile-time/loading time mechanism so it can not replace all the use cases of Lookup.in().

> 
> David

Rémi