record components as a first class reflection element
Brian Goetz
brian.goetz at oracle.com
Wed Sep 25 14:40:31 UTC 2019
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.romero at 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
More information about the amber-spec-experts
mailing list