Draft JVMS changes for Nestmates

[John Rose]

On Apr 19, 2017, at 2:10 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> I find these names very good - granted I've been working with them more than anyone else (but didn't define them). The plurality makes it clear to me.

+1 for plurality; that does it for me too, although it is a one-letter hint.

I'm happy with the names, though I have a little problem (that Dan is trying to fix)
with making clear the distinction between a Nest and the Host (or Top or Root) of
a Nest.  Things get messy when conflate them, which terminology can help avoid.

— John

P.S. Can't resist, so OK, in the spirit of "crib", how about throwing a private "party"?

Background:  The asymmetry of the relation is essential to the design of the attributes.

But it does not come from one class being somehow semantically or syntactically
distinguished in any way, other than one:  The special "nest host" (or "nest top")
is responsible for inviting any number of classes (including zero) to join its nest.

(The nest host is like the admin of a skype conversation, in which all conversants
are otherwise equal.  And like skype conversations, the group has only one purpose.
For nestmates, the purpose is to broaden the definition of ACC_PRIVATE.)

Under the theory that the nest host invites the other nestmates to the party,
we could emphasize that role in the attribute names:

NestMembers => NestInvitations (=> NestGrants since it is checked reactively)
MemberOfNest => RequestNest (=> Nest, or NestHost—requesting is a given when we do access control)

(Hmm…  NMs => PartyInvitations, PartyRoster; MoN => RSVPToParty, JoinParty.)

So, at this point, the best I change I can suggest to strengthen the asymmetry,
but keep the nicest metaphor (nest) is NestGrants / Nest or NestHost.

Why isn't "Nest" ambiguous?  Doesn't it define a nest?  Well, no, if you look
at the way attributes are named in the JVMS, they refer to an "attribute"
(duh) of the containing object.  Thus, if ClassFile has a Nest attribute, it
means that the ClassFile *has* an attribute of type Nest, not that the ClassFile
is defining another entity of type Nest *outside* of the ClassFile.  So I claim
that "Nest" is perfectly unambiguous:  It means that the ClassFile is asserting
the identity of its Nest, using the convention of naming the nest-host.
Choosing the more specific term "NestHost" would make it more clear
that the Nest is being named by mentioning its host.

The word "host" is a good fit (better than top or root) if we are emphasizing
the fact that the host's job is to grant entry into the nest.

Although reusing "host" is a feature rather than a bug, it could also be
NestSecretary, NestDoorman, NestMaitreDeHotel, NestBouncer, etc.

OK, I'm stopping.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20170419/727cc1e4/attachment-0001.html>