on implementing state components as a first class concept

[Vicente Romero]

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