on implementing state components as a first class concept
Vicente Romero
vicente.romero at oracle.com
Fri Apr 26 18:43:03 UTC 2019
On 4/26/19 2:26 PM, Brian Goetz wrote:
>
>
> On 4/26/2019 2:04 PM, Joe Darcy wrote:
>>
>> so I thought a more prominent existence for "state component" as
>> opposed to "just a private field" was called for. It would also be
>> possible to do more or less what the implementation does now where
>> the fields are marked with a kind of STATE_COMPONENT rather than
>> FIELD. The conceptual question is then are the state components just
>> fields with special handling or are they something that gets turned
>> into fields (and methods and parameters...)? If they are just fields,
>> the STATE_COMPONENT kind is still needed and the method on
>> TypeElement could be dropped. Especially when reading a record from a
>> class file, I think some indication will be needed state component
>> versus normal instance field since I would suspect compilers (and
>> potentially programmers at some point) will find a need for instance
>> fields beyond just the state components.
>
> 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
>
>
Vicente
More information about the amber-dev
mailing list