----- Mail original ----- > De: "Maurizio Cimadamore" <[email protected]> > À: "Vicente Romero" <[email protected]>, "Remi Forax" > <[email protected]>, "Brian Goetz" > <[email protected]> > Cc: "amber-spec-experts" <[email protected]> > Envoyé: Samedi 12 Octobre 2019 22:47:07 > Objet: Re: Record attribute binary format
> On 12/10/2019 02:36, Vicente Romero wrote: >> >> >> On 10/11/19 6:50 PM, Maurizio Cimadamore wrote: >>> >>> On 11/10/2019 22:19, [email protected] wrote: >>>> ----- Mail original ----- >>>>> De: "Brian Goetz" <[email protected]> >>>>> À: "Remi Forax" <[email protected]>, "amber-spec-experts" >>>>> <[email protected]> >>>>> Envoyé: Vendredi 11 Octobre 2019 22:57:23 >>>>> Objet: Re: Record attribute binary format >>>>> No need. Varargs-ness is reified with the (mandated) canonical ctor. >>>> hum, this looks like a hack, it means you can not just read the >>>> Record attribute, you have to crawle all the methods to find the >>>> primary constructor. >>> >>> It _looks_ like an hack, but I think that, after some more thinking >>> it's actually more correct than what you are proposing. A record >>> contains a bunch of components, the components have a name and a >>> type. Vararg-ness is immaterial here; both >>> >>> record Foo(Object[] arr) { ... } >>> >>> and >>> >>> record Bar(Object... arr) { ... } >>> >>> Denote the same underlying state (e.g. an Object array). The only >>> difference between Foo and Bar is that their _construction protocol_ >>> is different (which might also mean, in the future, that Bar will get >>> more liberal _deconstruction_ protocols too!); but this is cleanly >>> captured in the canonical constructor method_info. >>> >>> Pedagolical test: would an 'isVarargs()' predicate on the core >>> reflection record component be acceptable? >> >> that method as already added to j.l.r.RecordComponent, see [1], > > The link is not working ATM, but in any case, I don't think I like that > too much. This will return false always, except for, in some cases, the > last record component. > > It's not a single method _parameter_ that is varargs. It's the whole method. > > In the same way, I think that reasoning of a single record component as > 'varargs' is a red herring. Ok, i change my mind on this :) I agree with you that currently we only have varargs methods/constructors, there is no varargs parameters. So a "..." on the type of the last record component means that the record itself is a varargs not that a peculiar record component is a varargs. But technically a varargs record only means that when constructing a record, the canonical constructor is a varargs. So the method isVarargs() should be removed from the java.lang.reflect.RecordComponent. BTW, Should java.lang.Class have a method getCanonicalRecordConstructor() ? BTW2, if in the future we need some access flags on record components, we can still add a new attribute like MethodParameters on the Record attribute, so the current binary format is Ok. > > Maurizio Rémi
