Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    anupsv
    @anupsv
    😀, although it works I'm gonna improve it more with immutable classes....
    Tony Arcieri
    @tarcieri
    looks like two people :worried:
    apparently this is a better place to discuss stuff
    anupsv
    @anupsv
    Hehe
    I'll join the Google group soon
    Tony Arcieri
    @tarcieri
    I'd say the major remaining issues are:
    Floating point syntax: tjson/tjson-spec#43
    Boolean syntax: tjson/tjson-spec#44
    Nullability: tjson/tjson-spec#42
    Full type signatures for objects: tjson/tjson-spec#41
    Nice-to-haves are:
    Tuples: tjson/tjson-spec#38
    Sets: tjson/tjson-spec#22
    anupsv
    @anupsv
    Hmmm.....tuples and sets seem nice to have... But issues first
    Ill look at floating point tomorrow
    see the best methods to go bout this
    Tony Arcieri
    @tarcieri
    I'm not finished specing it yet, but it's pretty much guaranteed to be f for 32-bit single-precision floats, d for 64-bit double-precision floats stored in strings, both as specified in IEEE754-2008
    there's an open question as to whether f should be stored in a string or as a JSON floating point literal (or both)
    anupsv
    @anupsv
    a json floating point may have different behaviors
    a string would be logically more likely , but then again, need ways to distinguish
    Tony Arcieri
    @tarcieri
    RFC 7159 is unfortunately a bit vague on all of this :worried:
    This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision.
    i.e. precision is an implementation detail
    anupsv
    @anupsv
    huh
    Tony Arcieri
    @tarcieri
    I think it's reasonable to expect single-precision 32-bit floats to be ubiquitously supported
    as a native type
    anupsv
    @anupsv
    yep
    anupsv
    @anupsv
    So boolean will have "v"
    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