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