On Jan 21, 2016, at 3:10 PM, Vlad Ureche <[email protected]> wrote: > > Thank you for sharing these insights Brian! > > I think I understand the problem and the solution, but let me ask three > questions to make sure I understood well: > > 1) The NestTop attribute must contain the child classes (except > specializations and lambdas, which are added dynamically), right? Is this for > security, so another class could not pose as a NestChild to access private > data? What about allowing the NestTop attribute to say "anyone who wants to > nest here is welcome to do so"?
No, the security property comes from the bidirectional links. The top class could be anywhere. We are deliberately avoiding linking the semantics of NestTop to the InnerClasses attribute. Java will of course use them in an aligned manner, but that's just a compiler choice. The main security property that seems important is that nestmates must all be in the same package, so that package access is a strict subset of nestmate access. (No new wormholes, please.) > 2) Why did you choose to have symmetry and transitivity? I understand that > having an equivalence relation allows partitioning, but it's not clear to me > why partitioning is important in this case. So the security model can be simple, based on containment: global < module < package < nest. > 3) Why is the NestChild limited to a single top class? See previous message. It could be a more complex graph, but why bother with it? Any benefit from having a graph depth greater than one link? (Not a rhetorical question!) — John > These questions stem from pondering whether we can use the nestmates > mechanism to implement Scala's enclosing-entity-private access specifiers > (e.g. a variable in class List can be private[scala.collection.List] or > private[scala.collection] or private[scala])... Still, I don't think this can > be done at the granularity required by Scala, so we'll continue to have > name-mangled accessors where necessary :( > > Thanks, > Vlad
