On 10/7/19 3:31 PM, Chris Hegarty wrote:
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.
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
