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