Draft Object Serialization Specification for records - construction/destruction

[Chris Hegarty]

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.