on implementing state components as a first class concept

[Joe Darcy]

On 4/25/2019 1:17 PM, 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.

The build-in fields in the proposal area private and final and are 
implicitly set in the generated portions of the default constructor. The 
accessor methods are public and have a matching name.

Are there use-cases where direct access to the private fields in 
constructors is necessary?

Cheers,

-Joe