Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85647
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.174 as permitted sender)
MIME-Version: 1.0
Sender: jakub.php@gmail.com
In-Reply-To: <551B9704.4030302@gmail.com>
References: <CAEKnhAHjM2RY+Z2iB7D5wAb=FA43vMkKb1+34O-rTsuV222YUg@mail.gmail.com>
	<551B9704.4030302@gmail.com>
Date: Wed, 1 Apr 2015 19:45:01 +0100
Message-ID: <CAEKnhAEjGKLR3iEREywj79X7n7fM=agL69PbR4oTpUvpTW6BgA@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bdc1686dd4d4f0512ae1cfd
Subject: Re: [PHP-DEV] JSON float number as string
From: bukka@php.net (Jakub Zelenka)

--047d7bdc1686dd4d4f0512ae1cfd
Content-Type: text/plain; charset=UTF-8

Hi Stas

On Wed, Apr 1, 2015 at 7:58 AM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:
>
>
> > 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.
>
>
The encoding was just about re-using it. I wouldn't probably propose such
constant if it was just for encoding (the main purpose is decoding though).
I just thought that it could be a good idea to have some usage for encoder
if it's added. It seemed to me better than just ignore it completely for
encoder. What do you think?



> > 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.
>
>
I didn't mean it for json_encode ( apology for that as it might have seemed
that is related just to json_encode). I meant it just as "a sort of" bug
for json_decode as we loose information without giving user any way how to
prevent it or at least some note in documentation about that.

Cheers

Jakub

--047d7bdc1686dd4d4f0512ae1cfd--