[OPEN-ILS-DEV] PATCH: osrf_json_utils.h (scientific notation)

[Scott McKellar]

--- Bill Erickson <erickson at esilibrary.com> wrote:

> In principle, I agree with the manifesto.  The obvious problem is
> that 
> the (potentially flawed) logic of converting a JSON number into an 
> integer has to live somewhere.  Naturally, the application could
> better 
> anticipate the type of data it's expecting, but if each application
> has 
> to implement its own  string-to-number logic, it seems like that's 
> encouraging a lot of code duplication.

The manifesto is deliberately doctrinaire and intemperate.  A more
pragmatic approach would be to offer a default numeric translation,
but provide enough hooks that the application can supply its own.  

However it would be a mistake to add too much sophistication.  In
particular I would be reluctant to provide translations to and from
an integral type,  There are just too many choices available about 
how to handle rounding, overflow, scientific notation, and error 
reporting.  We don't have that capability today, and presumably there
is no need to add it immediately, if ever.

C already provides strtoul() and its kindred.

> Just a thought, what if the JSON number functions reported any loss
> of 
> precision?
> 
> int num;
> int status = jsonToNumber(obj, &num);
> 
> Then, let the application decide how it wants to proceed after
> receiving 
> a bad status. 
> 
> Is it always possible to know when a loss of precision has occurred?
> 
> This would still require a good bit of work, but it provides a common
> 
> framework for applications to use.

I think what you mean is that the return code would indicate whether 
there were any non-zero digits to the right of the decimal point.  
Such a feature would have to take scientific notation into account.
For example, "3E-7" has a non-zero digit to the right of the decimal,
even though there is no decimal point in the character string.

While such a feature might be useful, I'd rather not include it in
the JSON API, for two reasons:

1. It would incur extra overhead in cases where it was neither needed
nor used.

2. It shouldn't be confined to jsonObjects.  I'd rather provide a 
generic isInteger function (or maybe isFloat) that could be applied
to any character string.

Scott McKellar
http://home.swbell.net/mck9/ct/