[core-libs] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control

[David Holmes]

On this topic ...

On 21/05/2018 4:48 PM, David Holmes wrote:
> Hi Peter,
> 
> On 21/05/2018 4:12 PM, Peter Levart wrote:
>>
>>
>> On 05/21/2018 07:57 AM, David Holmes wrote:
>>> Do we really need to spell out the case for primitives and arrays? If 

May I add that getEnclosingClass() doesn't explain that primitive and 
array classes are considered top-level classes. Similarly getNestHost() 
doesn't explain that they are not explicitly nested classes.

Note: it was deliberate to not phrase this in terms of top-level classes 
in case in the future we want to expand the notion of nestmates further 
(such as "all classes defined in the same compilation unit form a nest").

Thanks,
David
-----

>>> so would it suffice to add the following:
>>>
>>> "A class or interface that is not explicitly a member of a nest 
>>> *(such as primitive or array classes)*, is a member of the nest 
>>> consisting only of itself, and is the nest host. Every class and 
>>> interface is a member of exactly one nest." 
>>
>> That's fine, but then someone might wonder whether only primitive and 
>> array classes are not explicit members of a nest.
>>
>> What about:
>>
>> "A class or interface that is not explicitly a member of a nest 
>> *(including but not limited to primitive and array classes)*, is a 
>> member of the nest consisting only of itself, and is the nest host. 
>> Every class and interface is a member of exactly one nest."
> 
> But "including but not limited to" is just a more verbose way of saying 
> "such as". "such as x" introduces an example case x, hence "including 
> x", but is not exhaustive and so covers "not limited to x".
> 
> David
> -----
> 
>> Regards, Peter
>>