Re: Universal Binary JSON Specification
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 big-endian ordered bytes representing a BigInt]
bigdouble - marker 'W'
[W][222 big-endian ordered bytes representing a BigDecimal]
--- In email@example.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.
- On Mon, Feb 20, 2012 at 9:42 AM, rkalla123 <rkalla@...> wrote:
> Stephan,For what it is worth, I also consider support for only signed values a
> 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.
-+ Tatu +-