Draft Object Serialization Specification for records - construction/destruction

[Peter Levart]

On 10/7/19 3:31 PM, Chris Hegarty wrote:
> Peter,
>
>> On 6 Oct 2019, at 22:38, Peter Levart <peter.levart at gmail.com> wrote:
>>
>>> ...
>> Here's a snipped from above draft:
>>
>> """The serialized form of a record object is a sequence of values derived from
>> the final instance fields of the object. The stream format of a record object
>> is the same as that of an ordinary object in the stream. During
>> deserialization, if the local class equivalent of the specified stream class
>> descriptor is a record class, then first the stream fields are read and
>> reconstructed to serve as the record's component values; and second, a record
>> object is created by invoking the record's canonical constructor with the
>> component values as arguments (or the default value for component's type if a
>> component value is absent from the stream).
>> """
>>
>> I think that if stream values deserialize into a record through its public API
>> (the canonical constructor which can be customized), then record components
>> that are serailzed must also be obtained from a record via its public API (the
>> accessors which can also be customized).
>>
>> I think this is an important aspect which should be spelled out in the
>> specification. So instead of: "The serialized form of a record object is a
>> sequence of values derived from the final instance fields of the object.", the
>> text should go: "The serialized form of a record object is a sequence of
>> values derived from invoking the record component accessors.”
> You are not wrong. In fact, I had the very same thought ( and the implementation does similar ), but we want to leave room here for deconstructors/extractors. With the wording in the current draft, it will be possible to switch the implementation without the need to update the specification.
>
> -Chris.
>
Yeah, but now the spec explicitly spells out that: "The serialized form 
of a record object is a sequence of values derived from the final 
instance fields of the object.", which is wrong. Imagine a custom 
accessor doing some normalization instead of canonical constructor, 
because record author wants to preserve information for internal logic. 
In the future, deconstructors/extractors would probably have to specify 
that they must be aligned with accessors. Perhaps the spec should speak 
about "component values" and then specify that currently the only way to 
obtain them is via accessors.

Regards, Peter