Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Frank Celler
    @fceller
    Thanks a lot
    Tony Arcieri
    @tarcieri
    @fceller under the current spec array types must be homogenous
    and yeah, floats need documentation re: the type annotation, but it's f
    Frank Celler
    @fceller
    @tarcieri thanks for clarifying the float.
    I assume something similar is valid for booleans and null?
    How would one deal with inhomogeneous arrays? Mixing integers and strings might not that relevant. But null values in a list of somethings are not uncommon?
    For instance if the result is a generated by database query it might happen, that there are null entries.
    Tony Arcieri
    @tarcieri
    The spec doesn't specifically address nullability, but as you say it's used commonly enough the entire type system probably needs to be treated as nullable everywhere. Nullability is a little different from heterogenous types though, or at least a special case
    re: arrays of disparate types, I proposed typing them as tuples: tjson/tjson-spec#38
    anupsv
    @anupsv
    Hi @tarcieri
    im new here but been following tjson for a while now :)
    Tony Arcieri
    @tarcieri
    Hi there @anupsv
    Tony Arcieri
    @tarcieri
    Saw your Python implementation. Awesome
    anupsv
    @anupsv
    Thanks a lot Tony
    Tony Arcieri
    @tarcieri
    I should probably send an email to the Google Group about the remaining open issues, although I'm not sure how many people actually signed up
    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: