Loading ...
Sorry, an error occurred while loading the content.

Re: [json] Universal Binary JSON Specification

Expand Messages
  • Stephan Beal
    ... Keep in mind that JSON does not specify any required numeric precision, and some platforms cannot use int64. (JavaScript specifies 53 bits of precision, in
    Message 1 of 76 , Sep 21, 2011
    • 0 Attachment
      On Wed, Sep 21, 2011 at 3:15 PM, rkalla123 <rkalla@...> wrote:

      > **
      >
      > The only difference from JSON being that "Number" is broken out into:
      > int32, int64 and double types for the purposes of making parsing of the
      >

      Keep in mind that JSON does not specify any required numeric precision, and
      some platforms cannot use int64. (JavaScript specifies 53 bits of precision,
      in case it matters.) e.g. in C89 there is no _portable_ int64 construct
      (that was introduced with C99, but lots of projects still use/require C89
      because of the very different levels of C99 support in various compilers). i
      know that Java is everyone's special baby, but some of us actually write
      JSON-consuming/producing C89 code. In the world of C++, Google's v8
      JavaScript engine doesn't support 64-bit integers: numbers >32 bits need to
      be doubles on that platform.

      In any case, i currently have a use case which will eventually require some
      type of binary support, and i will be reading through what you've posted.
      Thanks for sharing :).

      Happy Hacking!


      --
      ----- stephan beal
      http://wanderinghorse.net/home/stephan/


      [Non-text portions of this message have been removed]
    • Tatu Saloranta
      ... For what it is worth, I also consider support for only signed values a good thing. -+ Tatu +-
      Message 76 of 76 , Feb 20 9:55 AM
      • 0 Attachment
        On Mon, Feb 20, 2012 at 9:42 AM, rkalla123 <rkalla@...> wrote:
        > Stephan,
        >
        > No problem; your feedback are still very applicable and much appreciated.
        >
        > The additional view-point on the signed/unsigned issue was exactly what I was hoping for. My primary goal has always been simplicity and I know at least from the Java world, going with unsigned values would have made the impl distinctly *not* simple (and an annoying API).
        >
        > So I am glad to get some validation there that I am not alienating every other language at the cost of Java.

        For what it is worth, I also consider support for only signed values a
        good thing.

        -+ Tatu +-
      Your message has been successfully submitted and would be delivered to recipients shortly.