on implementing state components as a first class concept

[Brian Goetz]

100% on the second.

On the first -- assuming you are speaking _strictly_ of JLM modeling -- 
that works.  You can call them "class variables", or record components, 
or whatever.

AN open issue on the second is how annotations on record components are 
stored in the classfile.

On 4/26/2019 5:13 PM, Joe Darcy wrote:
> To check on the current goal-state of record modeling:
>
> * The state components will have a model separate from the same-named 
> fields, methods, and constructor parameters.
>
> * The class file will have a record attribute to store this 
> information, which will be used both by core reflection and 
> javax.lang.model to reconstruct the record-specific information.
>
> Agreed?
>
> Thanks,
>
> -Joe
>
> On 4/26/2019 12:06 PM, Vicente Romero wrote:
>>
>>
>> On 4/26/19 2:52 PM, Brian Goetz wrote:
>>>
>>>>> Semantically, a record
>>>>>
>>>>>     record R(int x) { }
>>>>>
>>>>> has _both_ an instance field called 'x' (which is private, and can 
>>>>> be referenced from the body of the class), and a state component 
>>>>> called 'x', and these are not the same thing.  The state component 
>>>>> does not intrude directly on the programming model, but should be 
>>>>> captured in the class file (so we know we are compiling against a 
>>>>> record), and exposed reflectively (so you know that a class is a 
>>>>> record and not just a class that happens to have some fields and 
>>>>> accessors.)  Record-ness is semantic, so it should be reflected as 
>>>>> such.
>>>>
>>>> We discussed other ways to capture in the class file that a class 
>>>> is a record: extending a common super class and / or adding an 
>>>> annotation to all records. One, or both, of these options should be 
>>>> enough for tools to know that they are dealing with a record. If 
>>>> additional information should be captured about the state 
>>>> components, fine but that information shouldn't probably determine 
>>>> if a given class is a record or not
>>>
>>> Extending a superclass should be enough to determine record-ness, 
>>> but only if the language prohibits non-record classes from extending 
>>> it. But, a superclass is not enough to capture the component 
>>> metadata, and we dont' actually have any other need for a 
>>> superclass, so we should probably drop it. Similarly, annotations do 
>>> not carry linguistic semantics.  So if we want a record to be 
>>> something semantic, and not just a macro expansion, there should be 
>>> a Record attribute in the classfile that captures everything about 
>>> the record (such as names, annotations, and signatures of its 
>>> components.)
>>
>> right I forgot, the Record attribute which is already implemented, we 
>> should probably enrich it with annotations for the components which 
>> is still missing
>>
>>>
>>>
>> Vicente