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
