Implementing Towards Better PEP/Serialization
Brian Goetz
brian.goetz at oracle.com
Mon Aug 17 18:03:10 UTC 2020
> the key to the proposal the following points:
> - What we're working towards is not really about serialization, it is
> about ep-pairs between Data ("dead" objects) and "live" objects.
Right; this is a "decomplection" move. The current serialization
complects graph walking, state extraction, wire encoding, decoding, and
reconstruction. By factoring out a transform between an internal and
external representation, the whole back end of that stack -- state
extraction, encoding, and decoding -- becomes separable. The language
supports state extraction and reconstruction, and encoding/decoding
becomes a purely external problem, where different frameworks can pick
their encodings according to their metrics.
> - A Record is currently the closest thing in Java to Data ("dead"
> objects).
Yes, there's a reason we call them "nominal tuples."
> - The metadata required for serialization is the same as what
> getRecordComponents provides, so why re-invent the capability.
This is one reason why records are a good candidate for being a data
representation substrate -- because they carry some of their metadata --
but they are really just one good candidate.
> - Unfortunately Data is not restricted to Record classes, however, if
> we can Duck type a class to a Record, we've got the information we
> need for serialization and plenty of other purposes.
Connects to previous comment.
> - Live objects that can't be Duck typed to a Record can optionally
> provide pe-pairs to export Data classes.
Key point here is that a serializtion library can use a whole bag of
moves to map Data <--> Object, and pick their own priority ordering of
tricks.
More information about the amber-dev
mailing list