question about java.lang.reflect.RecordComponent API

[Vicente Romero]

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>