Serialization of object identity

[Brian Goetz]

> Cycles are one thing but object identity is also needed to maintain 
> the shape of object graph in case it is a lattice (not a tree).
> Is the proposal assuming that there are references to shared instances 
> and it should be preserved during serialization/deserialization?

That's up to the serialization framework.  I could imagine some would 
choose to use identity to preserve topology, and others could choose not 
to (at the risk of duplication.)  And different frameworks can make 
different choices.  Java serialization already makes a pretty reasonable 
attempt to preserve topology, so presumably it would continue to do so.

Another aspect that is left to the serialization framework is _how_ to 
find a serializer for a given type.  For example, suppose you have a 
subtype of List, but which doesn't have any serialization members.  
Should we fail because we can't find a serializer/deserializer that will 
give perfect fidelity, or could we fall back to a generic 
serializer/deserializer pair (perhaps found in List) that would 
reconstruct an ArrayList or a List.of(...) list?  We don't have to make 
one choice for all serialization frameworks.

The emergent property here, that may not be obvious, is that once we 
move responsibility for state extraction/reconstruction to the class 
itself, core serialization becomes _less relevant_, because there is a 
"level playing field" that allows any serialization framework to 
participate, without privilege, in the state extraction/reconstruction 
part.  Then the job of a serialization framework becomes much simpler: 
finding serializers for classes, encoding, and decoding.