Nestmates

[Andrey Breslav]

I think, this thread shows that JVM-language tend to struggle with
visibilities one way or another. Even pre-Valhalla Java does, with nested
classes.

I understand that stretching the nestmate concept beyond what it's meant
for is not likely to happen, but for the record and for us to be aware of
the possible benefits in case we will be reconsidering some aspects of it
at some point I'll describe another use case that we have in Kotlin briefly.

Kotlin has the notion of "internal" visibility (visible inside the module,
which is a group of source files + declared dependencies), the granular,
per-member, form of which is apparently gone from Jigsaw.

What could help us there would be, for example
- having a class belong to multiple nests (still handshake-based, each nest
identified by a canonical member);
- opening a particular member only to some of the nests (one would suffice
for our use case, but that would mean creating synthetic classes just to
designate a new nest).

As I gather from the previous messages in this thread, this looks too
complex at the moment, so just saying :)

On Fri, Jan 22, 2016 at 2:11 AM Vlad Ureche <vlad.ureche at gmail.com> 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"?
> 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 :(
>
> Thanks,
> Vlad
>
-- 
Andrey Breslav
Project Lead of Kotlin
JetBrains
http://kotlinlang.org/
The Drive to Develop