Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85625
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.41 as permitted sender)
Message-ID: <551B9704.4030302@gmail.com>
Date: Tue, 31 Mar 2015 23:58:12 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Jakub Zelenka <bukka@php.net>, 
 PHP internals list <internals@lists.php.net>
References: <CAEKnhAHjM2RY+Z2iB7D5wAb=FA43vMkKb1+34O-rTsuV222YUg@mail.gmail.com>
In-Reply-To: <CAEKnhAHjM2RY+Z2iB7D5wAb=FA43vMkKb1+34O-rTsuV222YUg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] JSON float number as string
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> JSON_FLOAT_AS_STRING
> decode: all float values will be decoded as string
> - It's often an issue for very large float values with many fractional
> digits that are coming from platforms that support larger float
> representation than double. In that case the conversion is lost and there
> is no way how to get it back (see http://bugs.php.net/68456 [pls ignore my
> initial dump comments when I didn't get the issue :)] and an example of the
> lost precision here http://3v4l.org/80iCh ). Converting the value to string
> keep the precision and resolves the problem.

This makes sense, though one should be careful as string and float is
not the same and if you re-encode it, you will have data corruption
(since if somebody using, say, Java, decodes it they'd have string where
it expects float and decoding will likely fail). But I guess since it is
an option, people that enable it will have to deal with it, e.g. by
never re-encoding the data back.

> encode: all float values will be encoded as string
> - re-using the constant for encoder makes sense if PHP creates JSON for
> platform that support lower float type (e.g. C float) and the precision
> loss is not acceptable

Here I'm not sure it makes much sense though. If it's float, it should
be float. It's valid JSON, so if the receiving side can not handle it,
it's their issue which they have to fix in their decoding. Just changing
the types of data when encoding JSON does not sound like a good idea.
Especially given that the reader may be some library like Java's
Jackson, where types are very important. Of course, we could add tons of
options like INT_AS_STRING, OBJECT_AS_STRING, etc. but I don't think
this is what json encoder should be doing.

> I think that this is more a bugfix as the precision is lost without any way

I don't see how it is a bugfix. Representing floats is imprecise, it is
known and not a bug. json_encode now produces completely valid
representation of the data, so no bug there either. I don't think
changing value types on encoding is a good idea.
-- 
Stas Malyshev
smalyshev@gmail.com