Implementing Towards Better PEP/Serialization

David Ryan david at livemedia.com.au
Wed Aug 19 10:08:09 UTC 2020


I think a useful intermediate artifact would be to flesh out a catalog of
> the ways that a class can be “data”, or how a class can map itself to/from
> “data”, along with a catalog of use cases of programming styles matching
> which ones work with which techniques?
>
>
ok, I should be able to work through a lot of this with the POC library as
a starting point. I've already noticed that now that the shape of "data" is
defined I now need to work out the same for an "atom" (anything encoded as
a single element in encoding), as some classes such as UUID should be
converted to string when encoding. I'll then build the serialization
library around this and see if it works; it should provide enough
experience to write a catalog.


> The main thrust of the TBS paper is identifying the compromises we have to
> make in order to make reconstruction proceed through the constructor.  But
> clearly, not all classes will be equally amenable to a one-size-fits-all
> treatment.
>

Agreed. If the experience with the library and catalog goes ok, the paper
should fall out from this without too much difficulty. My suggested paper
title is "Towards Serialization Decomplection". :)

Thanks,
David.


More information about the amber-dev mailing list