Kulla: API naming question JLS vs JVM class

[Robert Field]

On 06/21/15 16:12, Remi Forax wrote:
> <bikesheding on>

;-)

> We are talking about an enum value, so the name is not TYPE_DECL but 
> KeyKind.TYPE_DECL,

Yes, Key.Kind.TYPE_DECL

> the result is a name with a prefix component and a postfix component,

Though one can import jdk.jshell.Key.Kind

then use Kind.TYPE_DECL

Or, import static jdk.jshell.Key.Kind.*;

and use just TYPE_DECL

> i find these kind of name hard to read.

Certainly as a whole, and names with underscores I find visually 
confusing in general.

All a matter of trade-offs.

>
> but if KeyKind is mostly use with an import static, i'm fine with 
> TYPE_DECL.

User's choice.

In the tool, which is our use-case now, it gets used exclusively in 
switch-statements, so no prefix.

-Robert

>
> cheers,
> Rémi
>
> On 06/21/2015 10:45 PM, Robert Field wrote:
>> Two off lists responses --
>>
>> -------------------------
>>
>> I vote for: TYPE_DECL, VAR_DECL, METHOD_DECL.
>>
>> -------------------------
>>
>> "Type" usually references to a type not a declaration. Variable 
>> similarly.  And their Keys subclass off DeclarationKey. So, a _DECL 
>> suffix makes sense.
>>
>> -------------------------
>>
>> -R
>>
>>
>> On 06/20/15 19:19, Robert Field wrote:
>>> Keys for what is called a "class" in the JVM (that is a class, enum, 
>>> interface, or annotation interface in JLS speak) have Key.Kind.CLASS 
>>> and are instances of Key.ClassKey.
>>>
>>> This is awkward both in terms of documenting them (I'm referencing 
>>> the JLS) and because the SubKind values are JLS-speak:
>>>
>>>     CLASS_SUBKIND(Key.Kind.CLASS),
>>>     INTERFACE_SUBKIND(Key.Kind.CLASS),
>>>     ENUM_SUBKIND(Key.Kind.CLASS),
>>>     ANNOTATION_TYPE_SUBKIND(Key.Kind.CLASS),
>>>
>>> Looking at the JLS the syntax production is TypeDeclaration. So, I 
>>> think the Key.Kind should be changed to TYPE.
>>>
>>> It could be changed to TYPE_DECLARATION but then we would want to 
>>> also change VARIABLE and METHOD to
>>>
>>>    VARIABLE_DECLARATION
>>>    METHOD_DECLARATION
>>>
>>> Which would make use pretty verbose.  Could be abbreviated, but the 
>>> API currently mostly shies away from abbreviations.
>>>
>>> So, the choices are:
>>>
>>> (1)   TYPE   TypeKey
>>>
>>> (2)   TYPE_DECLARATION   TypeDeclarationKey
>>>
>>> (3)    TYPE_DECL   TypeDeclKey
>>>
>>> (4)    CLASS   ClassKey
>>>
>>> What do you all think?
>>>
>>> Thanks,
>>> Robert
>>>
>>
>