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.r...@oracle.com> wrote: > > On Apr 7, 2016, at 6:39 AM, Paul Sandoz <paul.san...@oracle.com > <mailto:paul.san...@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
