... Yes exactly right. You could encode every number that way and it would amount to parsing strings on the processing side, effectively performing on par withMessage 1 of 76 , Sep 26, 2011View Source--- In email@example.com, "Paul C. Bryan" <paul.bryan@...> wrote:
> Also presumably it's perfectly acceptable to encode numbers <= 64 bitsYes exactly right.
> in an "H" value.
You could encode every number that way and it would amount to parsing strings on the processing side, effectively performing on par with standard JSON parsing because you have the String > Number Type conversion taking place.
For performance minded folks, not great, but for someone with a unique need that wanted to make all values H-encoded, definitely something they are free to do.
... 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 +-