Brian, Peter,

On 09/10/2019 19:52, Brian Goetz wrote:
> ...
> I think there is room to support the future.  Here are some ways we could 
> extract the state from a record for serialization:
>  A. Scrape the fields.
>  B. Call the field accessors.
>  C. Invoke the canonical deconstructor (when we have them.)
>  D. Invoke a serialization-specific pattern if there is one (when we support 
> them.)
> Note that in a case of `record R(...) { }`, these are all the same -- the 
> default accessors return the field values, and the default canonical 
> deconstructor invokes the accessors.
> Clearly, if the user provides an explicit serialization member (whatever that 
> looks like), we should use that in preference to "default" serialization; 
> this is true for classes and records alike, it's just that the default 
> behavior differs between classes and records.  So when we get to New And 
> Improved Serialization, D presents no migration problem; we can say "if there 
> is a serialization pattern, use that, otherwise..."

Sure, makes sense.

> We can make the same argument for C, since in the absence of an explicit 
> dtor, which you can't write now, what you'd get from an implicit dtor is the 
> result of B.  Same story: "if there is a canonical ctor, use that."

Agreed. So we can effectively decouple C & D from this discussion. Great.

> The real question is A vs B.  One can make an argument that serialization is 
> about raw object state, which means that field-scraping is OK.  Or one can 
> make the argument that we are trying to make serialization safer, so we 
> should prefer the accessor (when there is one.)  Most of the time, though, if 
> there is a nontrivial accessor, all it will do is make a copy (say, if the 
> corresponding component is an array), so going through the accessor is a bit 
> of a wasted effort.

The current wording in the draft comes from the desire to be precise on the 
deserializing-side, to ensure that record construction respects the object 
model. We may have overrotated on the serializing-side. It sounds like there is 
room for both A and B.

The proposed draft wording ( as referenced in Peter's earlier email ), from 
section 1.13 "Serialization of Records" [1] is:

 "The serialized form of a record object is a sequence of values derived from 
the final instance fields of the object."

This is not wrong ( remember the serialized-form is a description of the 
on-wire representation, not a description of how to derive the actual values ), 
but the word could be improved. Suggest:

 "The serialized form of a record object is a sequence of values derived from 
the record components."

The other area of the proposed draft spec where this impacts ( as referenced in 
Peter's earlier email ), is 2.1 "The ObjectOutputStream Class” [2]:

  "The components of the record object are written to the stream.

    a.  If the record object is serializable or externalizable, the record
         components are written, as if by invoking the `defaultWriteObject`
         method.  … "

I think that this is ok as is. It leave room for both A and B.

-Chris.

[1] 
https://cr.openjdk.java.net/~chegar/records/spec/records-serialization.03.html#serialization-of-records
[2] 
http://corelibs-linux-1.ie.oracle.com/~chhegar/webrevs/sv2/record/spec/records-serialization.html#the-objectoutputstream-class

Reply via email to