User model stacking: current status

[Brian Goetz]

>> 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.