on implementing state components as a first class concept

Joe Darcy joe.darcy at oracle.com
Fri Apr 26 21:13:44 UTC 2019


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


More information about the amber-dev mailing list