> You can use field names or you can encode the type alongside. Ex:
> { “birthdate”: [“date”, “01-02-1991”] }
> And then in your codebase you know that all the values in your data are actually a list of (type, value). In this specific case I’d decide a “date” as “mm-dd-yyyy”
This addresses neither of the problems I referenced from the article. The problem you've chosen to demonstrate is, indeed, trivial.
> It sounds like they want the equivalent to a Python’s pickle or PHP’s serialize.
They very much want the opposite. I wonder how you can read the article and conclude that they want an all-in-one serialization facility. The image at the end of the post well summarizes their position [0].
I have to agree with the other bloke, this is very much a problem in certain 'magical' JSON 'serializers' in certain very popular server languages, e.g. Java, Spring, FasterXML.
I've seen JSON ser done right where you do just ser/deser direct from/to a JSON object, then perform a manual mapping to domaim or business objects, I've seen it done the wrong way where the domain and data objects are highly coupled, by default.
I think the OP is bemoaning that being a common practice.
> { “birthdate”: [“date”, “01-02-1991”] }
> And then in your codebase you know that all the values in your data are actually a list of (type, value). In this specific case I’d decide a “date” as “mm-dd-yyyy”
This addresses neither of the problems I referenced from the article. The problem you've chosen to demonstrate is, indeed, trivial.
> It sounds like they want the equivalent to a Python’s pickle or PHP’s serialize.
They very much want the opposite. I wonder how you can read the article and conclude that they want an all-in-one serialization facility. The image at the end of the post well summarizes their position [0].
[0] https://einarwh.files.wordpress.com/2020/05/json-serializati...