Draft Object Serialization Specification for records - construction/destruction
peter.levart at gmail.com
Mon Oct 7 14:31:26 UTC 2019
On 10/7/19 3:31 PM, Chris Hegarty wrote:
>> 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.
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.
More information about the amber-spec-experts