vlad.ureche at gmail.com
Thu Jan 21 23:10:10 UTC 2016
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"?
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.
3) Why is the NestChild limited to a single top class?
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 :(
More information about the valhalla-spec-observers