on implementing state components as a first class concept

[Vicente Romero]

On 4/25/19 4:26 PM, Brian Goetz wrote:
> To be clear, you are not suggested having two _fields_ in the class file, right?  You are only talking about the JLM view of the world?

right this is only the JLM view of the world.

>
> For class file translation, fields, constructors, and methods are derived members, so we want to preserve everything about the declaration of the records somewhere, most likely an attribute that captures component names, signatures, annos, etc.
>
> So what you are suggesting is that in the JLM view, a record is seen as having two kinds of “class variables”, one set of fields and one set of “state components.”
>
> That we would end up distorting the translation of the fields to use a different name (even though this is an implementation detail) to avoid JLM issues suggests “tail wagging dog” to me.
>
> If the goal is that JLM clients should see record components as such, then perhaps we should expose records as a different kind of top level entity?

having a different kind of top level could be a solution, another option 
could be to represent all the needed information in the same field-like 
structure. One way to do this is making the compiler to add annotations 
to the fields / record

Vicente

>
>
>
>> On Apr 25, 2019, at 4:17 PM, Vicente Romero <vicente.romero at oracle.com> 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