Implementing Towards Better PEP/Serialization

[Brian Goetz]

>  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.