Peter, > On 6 Oct 2019, at 22:38, Peter Levart <peter.lev...@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.
