Re: record components as a first class reflection element

On Sep 24, 2019, at 1:47 PM, Vicente Romero 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 compo

Re: record components as a first class reflection element

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

Re: record components as a first class reflection element

On 9/24/19 3:33 PM, Alex Buckley wrote: At first glance, this is sensible because of the first-class status in the JLS of record components and their mapping to accessors. Based on a check of other implementations of AnnotatedElement, consider `boolean isVarArgs()` (IIRC a varargs component

Re: record components as a first class reflection element

Question - should RecordComponent extend java.lang.reflect.Member (after all, it has a name and a type). Not 100% sure. Maurizio On 24/09/2019 20:33, Alex Buckley wrote: At first glance, this is sensible because of the first-class status in the JLS of record components and their mapping to acc

Re: record components as a first class reflection element

At first glance, this is sensible because of the first-class status in the JLS of record components and their mapping to accessors. Based on a check of other implementations of AnnotatedElement, consider `boolean isVarArgs()` (IIRC a varargs component will be allowed) and `String toGenericStri

record components as a first class reflection element

Hi amber experts, We are considering our next move in the reflection area for records. It will be hoisting record components to a first class status in the reflection engine. Our current proposal is to define a new class named: java.lang.reflect.RecordComponent which will will be roughly defin

Re: Exploring inference for sealed types

Thanks Gavin.  We had an internal discussion on this today, which I will summarize here to help illuminate the issue. As Brian mentioned in an earlier email, sealed types address two related, but distinct, issues: (1) declaring a sum type, whereby the compiler can exploit exhaustiveness in vari