question about java.lang.reflect.RecordComponent API

[Maurizio Cimadamore]

Hi Vicente,
some random thoughts below.

1) A record component is *neither* a field, *nor* a method parameter. 
So, IMHO we should resist to all siren songs pushing for consistency in 
this or that direction. The spec is very clear on that:

"A record type R has the following members:

     For each record component appearing in the record component list:

         An implicitly declared private final field with the same name 
as the record component and the type as the declared type of the record 
component. This field is annotated with the annotation that appears on 
the corresponding record component, if this annotation type is 
applicable to a field declaration or type context.
"

That is, the record component is not even a member of the declaring 
record - the implicit private field is! So, on the basis of the spec I 
see no reason to bend the API this or that way.

2) Can you please confirm that RecordComponent::toString() is NOT 
printing generic type info?

3) A backlink from the component to the record declaration might be 
useful, and might shift the balance towards a more compact "int x" 
instead of "int Point.x"

4) We could also break with the past (after all this is a _new_ concept) 
and come up with a new way to rehash the same info, although, I have to 
admit it is quite hard to put (i) owner (ii) type and (iii) name in the 
same place w/o having my eyes hurt. "Point::(int x)" meh


Given I'm not super confident we will solve (4) any time soon, I think 
what we're doing now represents a pretty defensible fallback option. As 
I said, if we feel strongly about adding the backlink to the declaring 
record (which of course makes sense), we might considering shifting the 
polarity from more verbose (int Point.x) to more compact (int x).

Maurizio

On 05/11/2019 13:28, Vicente Romero wrote:
>
> Hi,
>
> I have got some comments in the CSR [1], that affect the API of 
> java.lang.reflect.RecordComponent. As I have also received comments on 
> the opposite direction I think this deserves a broader discussion. 
> Some context I have added a toString method to RecordComponent after a 
> review comment. The proposal was to make the method similar to 
> java.lang.reflect.Field::toString so the current spec of the method is:
>
> /** * Returns a string describing this record component, including * 
> its generic type. The format is: the generic record component type, * 
> followed by a space, followed by the fully-qualified name of the * 
> record class declaring the record component, followed by a period, * 
> followed by the name of the record component. * * @return a string 
> describing this record component, including its * generic type */
>
> On the other hand I got another suggestion to make the method more 
> similar to java.lang.reflect.Parameter, so removing the record class 
> declaring the component from the resulting string. Which direction do 
> we want to go? Consider that there is already a similar method, 
> ::toGenericString, with spec:
>
> /** * Returns a string describing this record component, including * 
> its generic type. The format is: the generic record component type, * 
> followed by a space, followed by the fully-qualified name of the * 
> record class declaring the record component, followed by a period, * 
> followed by the name of the record component. * * @return a string 
> describing this record component, including its * generic type */
>
> So any decision here should affect both. In addition I got another 
> suggestion to add a new method to j.l.r.RecordComponent: 
> `getDeclaringRecord` on the lines of 
> j.l.r.Parameter::getDeclaringExecutable. Comments?
>
> Vicente
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8233436
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20191105/bf77c13d/attachment.html>