Nestmates

[Brian Goetz]

>  Regarding Scala, the main problem is the granularity: setting the 
> visibility of each method
> individually goes far beyond the curly brace encapsulation model. I 
> think the only
> reasonable way short of having a Scala VM is to keep generating 
> accessors (or, as you
> suggested, making members public and reasoning about the accessibility 
> at language level).

It seems that Scala's accessibility model is finer-grained than what the 
JVM has in mind.  The JVM envisions three concentric rings -- everyone 
(public), library (package), and source file (private), plus the 
weirdness that is protected. Nestmates doesn't change that basic model, 
it just allows the compiler to have more latitude in clarifying the 
boundaries that determine private-ness (and to some degree protected-ness.)

> Regarding Peter's question, I assume the reason you want to have a top 
> of the nesting hierarchy is because you need to dynamically add new 
> nestmates, which is easier to do in one place than in all nestmates. 
> Right?
>

Dynamism is a part of it, but also (a) minimizing the error modes 
introduced by separate compilation and/or broken compilers (that then 
have to be checked at load time), and (b) minimizing the runtime 
overhead on classloading.  The current proposal is very light in terms 
of the load-time overhead -- for a top class, you just have to record 
the NestTop attribute, and for a child class, you just have to validate 
it (which is a straight lookup.)