3 ms·
Well, unlees you're using something like capnp, where O(1) contains is meaningful when O(n) deserialise is not acceptable. And really, if you have consumers/pr
by repsilat 8y ago
Well, unlees you're using something like capnp, where O(1) contains is meaningful when O(n) deserialise is not acceptable.
And really, if you have consumers/producers in different languages/codebases, built-in support for these things is a great convenience. You wouldn't say that objects/dicts in JSON are irrelevant, would you?
- derefr 8y ago> You wouldn't say that objects/dicts in JSON are irrelevant, would you? I kind of would. Coming from Erlang, I don't see a point to there being a whole separate syntax for encoding object/map types. Just encode objects/maps as arrays of pairs (2-Tuples, or just length-2 arrays). Then, if you want ser-des type fidelity, stick an annotation onto the array (like in YAML) to say what type it should decode to. E.g., something like: [1, 2, 3] # array [['a', 1], ['b', 2], ['c', 3]] # array of pairs [@object, ['a', 1], ['b', 2], ['c', 3]] # array of pairs hinted so it should decode to an Object [@map, ['a', 1], ['b', 2], ['c', 3]] # array of pairs hinted so it should decode to a Map The nice thing about this approach is that JSON libraries could do as much or as little work in parsing out the annotations as they want: they could recognize the annotations and construct the referred-to type; or they could just pass back the array with the annotation expressed as an Annotation value.