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

Re: Universal Binary JSON Specification

Expand Messages
  • rkalla123
    Don, I see your point. The way I understand it is that this would require 2 new data types, effectively BigInt and BigDecimal. So say something along these
    Message 1 of 76 , Sep 21, 2011
      Don,

      I see your point. The way I understand it is that this would require 2 new data types, effectively BigInt and BigDecimal.

      So say something along these lines:

      bigint - marker 'G'
      [G][129][129 big-endian ordered bytes representing a BigInt]

      bigdouble - marker 'W'
      [W][222][222 big-endian ordered bytes representing a BigDecimal]


      Thoughts?

      --- In json@yahoogroups.com, Don Owens <don@...> wrote:
      >
      > I've seen very large numbers used in JSON. In Perl, that can be represented
      > as a Math::BigInt object. And that is the way I have implemented it in my
      > JSON module for Perl (JSON::DWIW). Python has arbitrary length integers
      > built-in. For my own language that I'm working on, I'm using libgmp in C to
      > handle arbitrary length integers.
      >
      > JSON is used as a data exchange format. I want to be able to do a
      > roundtrip, e.g., Python -> encoded -> Python with native integers (with
      > arbitrary length in this case). In JSON, this just works, as far as the
      > encoding is concerned. I see the need for this in any binary JSON format as
      > well. If a large number is represented as a string, then on the decoding
      > side, you don't know if that was a number or a string (just because it looks
      > like a number doesn't mean that the sender means it's a number). If, when
      > decoding JSON, the library can't handle large numbers, it has to throw an
      > error anyway. The same should go for binary JSON.
      >
      > ./don
    • 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
        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.