Implementing Towards Better PEP/Serialization

[David Ryan]

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

Exactly, it's the object state/data we need to serialize (or build a DOM
with).

I did have to check this new language architecture term "decomplection".
Not much on the web. I think it needs some more papers written on it. :)


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

A POJO, Record or hand written immutable objects are all candidates for
being a data representation substrate. I'm saying that we could identify an
Object as being a Data class if it has or can be manipulated to have the
following properties.

 - It has an n-arg constructor that represents all the components of the
data.
 - It has n components which have a name, type and accessor Method and is
available at runtime.
 - In future it might also have an n-arg destructor.

A Record by design has these properties. A hand written immutable object
has these properties but currently can't be treated the same way. A POJO
has most of these properties and could have a synthetic constructor added
(or in my POC have some MethodHandle folding create a MethodHandle that
behaves the same way). If I can manipulate these different types of objects
as if they were Records the serialisation, or conversion to/from DOM or
other data structure becomes a lot simpler.


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

Yep, once you can identify which classes are Data and which are not, it
becomes a lot easier. For non-data objects (don't conform to above),
there's various ways to have them export state through the "convert to
data" options listed previously. I think it would be beneficial for the
language to provide some patterns to do this, but that can be part of a
serialization library.

>From here, I'll put these ideas into the POC I'm building. Already with a
few tweaks I'm noticing that by treating these different classes as having
those properties the implementation is becoming simpler.  Other than
providing some more experiences on that, is there anything I can/should do
to progress this concept?

Thanks,
David.