Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Tony Arcieri
    @tarcieri
    As presently proposed, yes
    anupsv
    @anupsv
    seems fine, shouldnt be complicated
    Nullability needs more thought
    Tony Arcieri
    @tarcieri
    yes
    I am a fan of making TJSON non-nullable for now
    anupsv
    @anupsv
    yep, that should work and may be with the next major version, we could add the alternative
    Tony Arcieri
    @tarcieri
    :thumbsup:
    Justin Fay
    @justinfay
    Hi @anupsv I forked your repo to https://github.com/justinfay/tjson-python/ and added the test suite, I had to make some small tweaks to get the test suite to run and there are still a few failures on py2/py3
    I also think you could do without the python-dateutil dependency as timezones should always be UTC
    anupsv
    @anupsv
    I'll look into it, i've not yet made it compatible to py3
    anupsv
    @anupsv
    Should'nt be that hard, will look into it this weekend
    Tony Arcieri
    @tarcieri
    For anyone curious about JavaScript: TC39 is discussing adding 64-bit signed and unsigned integers to JavaScript
    which should be supported by transpilers soon
    Tony Arcieri
    @tarcieri
    I am going to hold off on implementing the JavaScript version until that's available
    anupsv
    @anupsv
    yep makes sense
    tony, are u gonna add the new formats to the spec?
    Tony Arcieri
    @tarcieri
    yes, I think specing floats is the main thing that's immediately relevant
    Geofrey Ernest
    @gernest
    Umh! I have a question.
    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.
    Tony Arcieri
    @tarcieri
    @gernest I am only starting to learn Go, but in Rust you can assert the types are what you are expecting, and if not return an error
    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
    Geofrey Ernest
    @gernest
    @tarcieri I see
    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.
    Tony Arcieri
    @tarcieri
    yeah, and decoding an int64 will also handle the string->int64 conversion for you
    Geofrey Ernest
    @gernest
    But don’t ypou think it is overboard to have a string of int64?
    Tony Arcieri
    @tarcieri
    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
    Geofrey Ernest
    @gernest
    True. Go convert all numbers to int64
    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!
    Tony Arcieri
    @tarcieri
    I'm not sure what your concern is? int64 should decode as int64
    it's serialized as a JSON string to avoid losing precision
    Geofrey Ernest
    @gernest
    I see! I think I have some idea about how to proceed with the API. But I can clarify what I meant by example!
    consider this is th structure
    type Number struct{
       Double int64
    }
    it can be serialized to {“Double”:12345}
    easily
    Geofrey Ernest
    @gernest
    That can go both ways, serializing and deserializing.
    On the other hand, {“Double:i”:”12345"}
    doesn’t look right.
    correct me if I’m wrong!
    Geofrey Ernest
    @gernest
    And another thing, I can’t find any details on int64 on the spec!
    @gernest and yes, that serialization is correct