Re: [JSON][review] Design: what is expected of a "JSON library"?

From: Richard Hodges (hodges.r_at_[hidden])
Date: 2020-09-18 08:18:19

On Fri, 18 Sep 2020 at 09:40, Eduardo Quintana via Boost <
boost_at_[hidden]> wrote:

> > > // i want speed
> > > boost::json::parser< int  > p_int;
> > >
> > > // i want accuracy
> > > boost::json::parser< boost::multiprecision::cpp_int > p_infinity;
> >
> > By this example, can we assume you only care about this flexibility at
> > parsing level and not necessarily in the DOM-like object
> > (json::value)?
> >
>
> That what just for illustration purposes.
> I see that there are several objects involved.
>
> My point is: the concept of JSON is independent of the underlying
> types used for representing strings and numbers.
> That's, in my opinion, a strong suggestion for using templates,
> and a solution to the "precision vs speed" conundrum.
>
> Of course a json::parser<T>, has to produce a json::value<T>
> and yet json::value<T> can exists independently of a json::parser<T>
> or json::serializer<T>.
> Is up to the developers to choose how the abstraction is implemented.
>
> Anyways that was just a comment and a suggestion.
> If I was writting a json library I would have used templates.
>

Vinnie might have covered this already but here's my 2c.

JSON is in the main used as a language and platform agnostic data
interchange format. The *de-facto* reality is that every other platform and
language implementation that I can think of limits real numbers to doubles
and integers to the range +-2^63, so it seems to me that going beyond that
will achieve little in terms of general utility.

This is the situation today.

I understand the argument that this library could be an opportunity to push
the boundaries and lead other languages to better practice.

On the other hand, this is not the stated intent of the library - it's
intent (in summary) is to meet the needs of the majority of C++ programmers
who wish to interoperate with the world wide web today.

Along with others here I am sure, I have significant experience in dealing
with financial and cryptocurrency data interchange using JSON. The *reality*
is that one learns *not to rely on the various interpretations of number
values at all*.
If you're sending an important value (such as a price) you very quickly
learn to encode it as a JSON string representing the exact value and
precision you want.

In reality, JSON would be a perfectly useful data format if it did not have
numeric, boolean or null types at all. For this reason, it seems to me that
arguing over the precision of the API representation of these types is not
likely to lead to increased utility in practice.

Although I appreciate that some niche use cases would appreciate the
ability, it is my impression that these will be rare and in any case can be
worked around with strings.

R

>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

-- 
Richard Hodges
hodges.r_at_[hidden]
office: [phone]
home: [phone]
mobile: [phone]