on implementing state components as a first class concept

[Maurizio Cimadamore]

On top of my head, the way I'd approach this would be something like this:

1) keep using fields to model state components, but mark them with a 
special flag

2a) use the same VarSymbol implementation for both the state component 
and the field

2b) derive the state components from the VarSymbols marked with the 
corresponding flag

3) When users ask for state components 
(TypeELement::getStateComponents), generate the list as per either (2a) 
or (2b).

Is this a viable implementation path?

P.S.

I'm a bit skeptical of reusing VariableElement for state components, 
since that API is more general (e.g. see 
VariableElement::getConstantValue()). I'd rather like to see a new 
interface for state components, and maybe a common superinterface 
between state components and field elements.

Maurizio

On 25/04/2019 21:17, Vicente Romero wrote:
> Hi,
>
> Joe and I have been chatting offline about his proposal for making 
> record state components a first class concept. The closest concept 
> available in the compiler is, as seen from the javax.lang.model API: 
> j.l.m.e.VariableElement which is implemented by 
> com.sun.tools.javac.code.VarSymbol in javac. This is the same class we 
> use for parameters, fields, etc. This means that we will be having two 
> field-like structures inside the same class, inside the same scope and 
> with the same name.
>
> One way to overcome the same name issue could be to generate a 
> synthetic name for the private field, kind or $stateComponent, that 
> way the compiler won't have any issue attributing both field-like 
> entities. The problem with this is that user code added to the record, 
> will use the state component name so that user code will need to be 
> rewritten, at parser time?, so that it refer to the synthetic name 
> given to the private field. This is not a big deal but could generate 
> other side-effects.
>
> I'm not very happy with these options to implement state components as 
> a first class concept mostly because of the user code rewriting issue. 
> Other options could be to use the same field-like entities for both 
> purposes or annotate the record with the state components information.
>
> Comments?
>
> Vicente