The concern is that we need Foo.nestHost == Rational.nestHost and that
the common nestHost includes both Foo and Rational as nestMembers. To
do that, we need to load the nestHost class (if it isn't already).
Getting the interaction between the access check and the additional
class loads right (and clearly spec'd) is my concern.
My assumption - which I'm starting to question - is that Foo is an
invalid class if it isn't a nestmate to Rational and that attempts to
load Foo should fail.
Thinking about this more, there's a second model here which says Foo
is fine (after all we allow other classes to have fields of types they
can never fill in) but all attempts to resolve the 'myRational' field
will fail. This moves the nest mates check to resolution (similar to
existing nest checks) rather than during class definition. Is this
second model more what you had in mind?
Now its my turn to say you're ahead of me :)
From a language perspective, if X is inccessible to Y, then
class Y {
X x;
}
will fail compilation. If such a class sneaks by anyway, whether we
reject it when we load Y or when we try to resolve field x, those seem
mostly indistinguishable to me from a design perspective, since they'll
never be able to do the bad thing, which is use x when it is uninitialized.
But (and there's a whole conversation to be had here) it does mean that
there is separate access control on LFoo vs QFoo, and we have to either
prevent or detect leaks before they let us do something bad (like Y
reflectively creating an array of X.val). But this seems manageable,
and not all the different from the sort of leak detection and plugging
we do with reflection today.
