Re: [lworld] [Rev 01] RFR: rename verifier related value-types, rename JVM_SIGNATURE_VALUETYPE, …

[John Rose]

On Jun 16, 2020, at 6:25 AM, Frederic Parain <fparain at openjdk.java.net> wrote:
> 
> src/hotspot/share/classfile/verificationType.hpp line 245:
> 
>> 244:   bool is_array_array() const { return is_x_array(JVM_SIGNATURE_ARRAY); }
>> 245:   bool is_inline_array() const { return is_x_array(JVM_SIGNATURE_INLINE_TYPE); }
>> 246:   bool is_reference_array() const
> 
> The term "inline" alone can be misleading (is it about the element being an inline type, is it about the elements of
> the array being inlined in the array, is it about the array being inlined in something else, etc). Here, the check is
> about the kind of elements stored in the array, so I would suggest "is_inline_type_array()".

I actually have the opposite take on this (but it’s stylistic
and esthetic, so I’m OK with it going either way).
The term TYPE (and _type etc.) occurs too much in this
selection of names.  And it is permanently jarring to
have T_INT (not T_INT_TYPE) but T_INLINE_TYPE.
“Can be misleading” is a relative term; usually it isn’t,
and there are other ways to reduce mistakes than put
an extra noise-word everywhere.  The extra noise word
(“type”) can be annoying, and (more to the point) distracting
to the reader.  In other words, there’s such a thing as
too much information in a name, and I think we are
over the line with this set of choices.

— John