tony, are u gonna add the new formats to the spec?
For a typed language like Go. How does tjson fit in?
I know, I can generate tyson from Go types. But it is not possible to generate Go types from tjson at runtime.
all of that is largely accomplished through things like macros and trait derivation though
I know the Go JSON library does something sort of analagous with... metadata on map members or something to that effect?
regardless, in a statically typed language the whole "self-describing" aspect doesn't work out as well, but at the same time it should also cut down on the boilerplate you need to extract richer types from a JSON document
But that still doesn’t explain much. As if the field is an
int64 then your decoded value must me int64 . Although I realize now, the valuew can be verified further like the base64 string.
or more specifically: https://tools.ietf.org/html/rfc7159#section-6
Note that when such software is used, numbers that are integers and are in the range [-(2^53)+1, (2^53)-1] are interoperable in the sense that implementations will agree exactly on their numeric values.
JSON does not guarantee interoperable support for 64-bit numbers
this is true of both JavaScript and, I believe, Go, both of which convert all JSON numbers to doubles
I am working on a generator. That generate decoder/encoder methods of go structs.
So, I thought I can add tyson support too. This generates the code before compiling.
I analysed the case of decoding tjson data. And It bugs me a little , since you can store
int values to int field. If the tjson data has a sting field specified to be an int, at runtime it becomes harder to get the API right!
it's serialized as a JSON string to avoid losing precision
consider this is th structure
type Number struct{
Double int64
}
it can be serialized to
{“Double”:12345}
easily
On the other hand,
{“Double:i”:”12345"}
doesn’t look right.
correct me if I’m wrong!
@gernest and yes, that serialization is correct
here's a real-world example of integer precision problems in JSON: https://dev.twitter.com/overview/api/twitter-ids-json-and-snowflake
that should hopefully make its way into transpilers shortly thereafter, and there will finally be an interoperable solution
several changes to the spec: "b" for boolean, with binary data now "d"
and there is now a JavaScript (actually TypeScript) implementation of the latest version of the spec: https://github.com/tjson/tjson-js
I'm just joined this rooms