RFR 8151705 VarHandle.AccessMode enum names should conform to code style

[Paul Sandoz]

Hi John,

I like the approach to hybrid names. I’ll follow up with another issue.

How about we go with:

  AccessMode.NAME_get;

etc.?

And for those that think best-practices are rules (style guide IMO are often best practices sprinkled with subjective reasoning) i can add an @apiNote explaining why the naming scheme was chosen.

Paul.

> On 11 Apr 2016, at 23:23, John Rose <john.r.rose at oracle.com> wrote:
> 
> On Apr 7, 2016, at 6:39 AM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote:
>> 
>>  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151705-VH-AccessMode-names/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151705-VH-AccessMode-names/webrev/>
>> 
>> I was persuaded (in internal CCC review) to change the enum VarHandle.AccessMode constant names to conform to the expected Java style.
> 
> I'm sorry you were persuaded, because in some of these cases it is the code style that needs to flex here, not the source code names.
> 
> When working with reflective representations of API points, there is no benefit from representing (say) a method called toString by a variable which is called TO_STRING.  It just makes it hard to see the correspondences between the ground names and the reflective names.  (To start with, grep and other tools will fail to find both names.)
> 
> This is why, in the original JSR 292 code base, I have chosen to use hybrid names for fields that reflect API points.  The prefix of the hybrid names does, in fact, follow the code style, but the suffix is the exact spelling of the reflected API point.  I would be sad if some officious soul "fixed" these divergent names, because it would obscure the code.  In fact, I wish this particular use case for hybrid identifiers were more widely recognized.
> 
> Examples:
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/8c293ee99d5a/src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java#l660 <http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/8c293ee99d5a/src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java#l660>
>                     NF_internalMemberName = new NamedFunction(DirectMethodHandle.class
>                             .getDeclaredMethod("internalMemberName", Object.class)),
> 
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/8c293ee99d5a/src/java.base/share/classes/java/lang/invoke/Invokers.java#l443 <http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/8c293ee99d5a/src/java.base/share/classes/java/lang/invoke/Invokers.java#l443> <http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/8c293ee99d5a/src/java.base/share/classes/java/lang/invoke/Invokers.java#l443>
>                 MH_asSpreader = IMPL_LOOKUP.findVirtual(MethodHandle.class, "asSpreader",
>                         MethodType.methodType(MethodHandle.class, Class.class, int.class));
> 
> As a precedent, the JVMS uses hybrid identifiers for quasi-reflective names like CONSTANT_String, etc.
> 
> Arguably (and also arguably not), the access types in your enums are quasi-reflective references to specific methods, and so should have their names derived (as a hybrid name) from the literal method names.
> 
> Good style includes knowing when to bend the rules.
> 
> — John