----- Mail original ----- > De: "Brian Goetz" <brian.go...@oracle.com> > À: "Vicente Romero" <vicente.rom...@oracle.com>, "John Rose" > <john.r.r...@oracle.com> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Envoyé: Mercredi 25 Septembre 2019 16:40:31 > Objet: Re: record components as a first class reflection element
> I think what John is saying is that once we have a reflective object to > describe the component, there's no need to actually go from there to the > method if we want to operate on it; we can just expose a `get()` method > right on the component. > > If we did this, then we'd want to also support > Lookup.unreflect(RecordComponent). yes ! or Lookup.unreflectGetter(RecordComponent) Rémi > > On 9/25/2019 10:15 AM, Vicente Romero wrote: >> >> >> On 9/24/19 8:38 PM, John Rose wrote: >>> On Sep 24, 2019, at 1:47 PM, Vicente Romero >>> <vicente.rom...@oracle.com> wrote: >>>> >>>> On 9/24/19 4:07 PM, Maurizio Cimadamore wrote: >>>>> Question - should RecordComponent extend java.lang.reflect.Member >>>>> (after all, it has a name and a type). Not 100% sure. >>>> good question, I would say yes, we can say that record components >>>> are members of the class, but I'm not 100% sure either >>> Turning this crank once more, I’d say that the presence of isVarArgs >>> and the generic >>> string as queries is evidence that we are looking at this factoring: >>> >>> (RecordComponent | Method | Constructor) <: Executable <: >>> (AccessibleObject & Member & GenericDeclaration) >> >> at first glance, RecordComponent <: Executable doesn't feel right to >> me even if there are common members >>> >>> In this account, “Method getAccessor” would become either >>> unnecessary, or a low-level sideshow. >>> >>> (Raising the question: Should the jlr.Method of an RC be synthetic, >>> or should the same API point >>> be reflected in two places?) >>> >>> — John > > Vicente
