question about java.lang.reflect.RecordComponent API
Vicente Romero
vicente.romero at oracle.com
Tue Nov 5 14:42:44 UTC 2019
Hi Maurizio,
Thanks for your feedback. It seems like we have material for today's
meeting :)
On 11/5/19 9:21 AM, Maurizio Cimadamore wrote:
>
> 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?
>
no it is not,
>
> 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
>
Vicente
>
> 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/619d3d54/attachment-0001.html>
More information about the amber-spec-experts
mailing list