----- 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

Reply via email to