Encoding longs as numbers

41 views
Skip to first unread message

David Barri

unread,
Jun 20, 2014, 8:16:06 PM6/20/14
to argona...@googlegroups.com
Hey,

I see that Argonaut uses a double to represent numbers, and that the default long encoder outputs strings. Fine when I read/write my own json but a problem when I'm interacting with some external APIs.

Is there a way to generate json like {"long":123456789} instead of {"long":"123456789"} and be assured that there won't be any corruption due to numeric type conversions?

https://github.com/argonaut-io/argonaut/issues/98 sounds like it will take care of the decoding flip-side.

Cheers,
David

seantparsons

unread,
Jun 21, 2014, 4:51:25 AM6/21/14
to argona...@googlegroups.com
The reason why it's been done like that is that otherwise there's an issue with a lack of precision. As the following REPL session should demonstrate:

scala> val longMax = Long.MaxValue.toString
longMax: String = 9223372036854775807

scala> longMax.parseOption
res0: Option[argonaut.Json] = Some(9223372036854776000)


scala> java.lang.Double.parseDouble(longMax)
res4: Double = 9.223372036854776E18


Now we're probably a bit more permissive than we really should be there as it's Double.parseDouble letting that one slip through the net, but until we move to arbitrary precision we're somewhat stuck with it.

Sean.

David Barri

unread,
Jun 28, 2014, 8:32:43 PM6/28/14
to argona...@googlegroups.com
Can you clarify what you mean by arbitrary precision? Is that the plan to carry numbers around as strings instead of doubles and have codecs parse them? Do you have an idea as to when this will happen?

Also, are you saying there's no way as it stands to generate {id:1}  instead of {id:"1"} with Argonaut? That's shocking, if so.

Mark Hibberd

unread,
Jun 28, 2014, 10:27:35 PM6/28/14
to David Barri, argona...@googlegroups.com
/cc the list this time :/

On 29/06/2014 10:32 am, "David Barri" <japg...@gmail.com> wrote:
>
> Can you clarify what you mean by arbitrary precision? Is that the plan to carry numbers around as strings instead of doubles and have codecs parse them? Do you have an idea as to when this will happen?

No we are going to change the data type and you will optionally be
able to use more precision. But there are awkward security
ramifications if you are not careful.

> Also, are you saying there's no way as it stands to generate {id:1} instead of {id:"1"} with Argonaut? That's shocking, if so.

You can, you just have to do it yourself as it is neither safe
(overflows) or portable (violates all by the current draft spec and is
not interoperable with any js impl). To do it, just write an encode
that maps your type to jNumber and decide what to do with overflow.

Cheers
Mark
Reply all
Reply to author
Forward
0 new messages