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

Re: [json] Re: Universal Binary JSON Specification

Expand Messages
  • Stephan Beal
    ... It specifies neither a limit nor a minimum, at least as far as i was able to dig out of the RFC a few months ago. A 2-bit limit is, strictly speaking,
    Message 1 of 76 , Sep 21, 2011
    • 0 Attachment
      On Wed, Sep 21, 2011 at 8:27 PM, Don Owens <don@...> wrote:

      > **
      >
      > length? I don't think the JSON spec puts a limit on the size of an integer.
      >

      It specifies neither a limit nor a minimum, at least as far as i was able to
      dig out of the RFC a few months ago. A 2-bit limit is, strictly speaking,
      legal.

      > If there is no way to encode large integers in your spec, people will
      > invent their own way of doing it -- it's better to have a standard way of
      >
      If they're concerned with JSON and its portability they'll "probably" (i
      naively assume!) use JavaScript's limits as their baseline. JavaScript
      doesn't separate int/double, and instead has a Number type with at least 53
      significant bits. In my own code i use JSON doubles in lieu of int64, which
      avoids the immediate incompatibility but probably also has range-related
      overflow/underflow issues when using "really, really large" values (which my
      uses cases haven't called for so far).

      --
      ----- 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, 2012
      • 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.