Thanks Chris. This looks sensible. A few questions inline.
- The serial form of a record is it's state components. It is not
customizable (*).
Must the fields appear in the stream in the canonical order? Or, are
they serialized by name, and then we swizzle them back into the order
desired by the canonical constructor?
- Serialization will ignore pretty much all of the magic methods, if
they appear in a record (**).
What about serialVersionUID?
What happens if the fields present are a superset, or subset, of the
components in the canonical ctor?
- Record-like class to record migration is supported (and vice versa),
since the stream format is not changed.
So, if a class C migrates to a record R, the serialized fields are just
fed to the canonical ctor. Must serialVersionUID match? Or maybe, if
at deserialization time it's a record, we just ignore svuid?
(**) we want to allow `writeReplace` as an escape hatch, in case for
example, a non-serializable type ends up as a component in a
serializable record, or maybe if one wants to replace the serializable
record with a proxy that, say, refers to a singleton value, or similar.
This seems reasonable.
