on implementing state components as a first class concept

[Vicente Romero]

On 4/26/19 5:28 PM, Brian Goetz wrote:
> 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.

I assume the annotations on record components will be stored in the 
Record attribute in the class file,

Vicente

>
> 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
>