----- Mail original ----- > De: "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:15:22 > Objet: Re: record components as a first class reflection element
> 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 they have more than that, when you write aRecordValue.aRecordComponent() it actually works ! You are actually calling a record component to get it's value, so it makes sense to see a RecordComponent as Executable. >> >> 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?) that's a very good question. I think that if getMethods() doesn't provide a Method object for the record component, this behavior will break a lot of code, so in my opinion, it should be reflected in two places. The other thing is that the return of getMethods() is in any order while i hope that the return of getRecordComponent() be to in the order of declaration (the order of the RecordComponent attribute for the VM). >> >> — John > Vicente Rémi
