Nestmates

[Brian Goetz]

> If I understand correctly, the "top" class is there just to simplify 
> the calculation of whether two classes belong to the same nest. 

It's a little more than that, but this is part of it.  Having a 
canonical member simplifies the calculation of "are A and B members of 
the same nest."  Conveniently, there *is* an obvious canonical member, 
so we might as well not make our life harder.

We need a way to refer to a nest.  Having a canonical member is ideal 
for that.

We need some way of (in)validating the claim "I am a member of the same 
nest as java.lang.String".  Having a canonical member, who can answer 
such questions authoritatively, is ideal for that.

Because the intention is that "nest" corresponds to some logically 
grouped source unit, and therefore a class may be a member of only one 
nest, we need some way of enforcing that a nest forms a partition.  
Having a canonical member makes this far easier.

> Are there any other functions that might be attached to the "top" 
> class? Will the top class have to be loaded in order to verify access 
> of one peer to another peer? Or will it just have to be parsed to 
> extract the NestTop attribute?

The obvious implementation strategies would likely bring us there. It is 
conceivable that we could delay loading the Top until its nest-ness 
credentials are needed, but that seems like it would add a lot of 
implementation complexity (and would keep us from failing fast.)  So its 
likely that this would happen.

However, this seems pretty likely without nestmate-ness too.  How often 
do we instantiate an enclosed class without loading the enclosing 
class?  (Never for instance inner classes.)  It happens, but usually 
only in cases where nesting is used "for organizational purposes only" 
(and in those cases, the enclosing class is usually trivial.)  So this 
doesn't seem a terrible constraint to me.

What other functions did you have in mind for what the Top can do to 
help its children?