Draft Object Serialization Specification for records - construction/destruction
Chris Hegarty
chris.hegarty at oracle.com
Mon Oct 7 13:31:51 UTC 2019
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.
More information about the amber-spec-experts
mailing list