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

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