... You have a very interesting way of reading specifications -- when spec does not limit magnitude or precision, you claim it s fine to use whatever size: byMessage 1 of 76 , Sep 22, 2011View SourceOn Thu, Sep 22, 2011 at 12:12 AM, Stephan Beal <sgbeal@...> wrote:
> On Thu, Sep 22, 2011 at 8:20 AM, Tatu Saloranta <tsaloranta@...>wrote:You have a very interesting way of reading specifications -- when spec
>> Yes, to properly support full JSON data set, one should provide
> i don't agree: JSON does not specify an integer size, which means that
> supporting only an 8-bit int is still valid JSON.
does not limit magnitude or precision, you claim it's fine to use
whatever size: by that logic, it'd be fine to only support values 0
and 1. Or just 0.
Put another way: if you only support a subset, then format can not
represent all valid JSON documents, and thus is just a subset, not a
As to not all environments having BigDecimal/BigInteger, that's a red
herring -- as long as you define exact format of data, any environment
can support it, even if by just exposing array of bytes.
-+ Tatu +-
... For what it is worth, I also consider support for only signed values a good thing. -+ Tatu +-Message 76 of 76 , Feb 20, 2012View SourceOn 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 +-