Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85770
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.181 as permitted sender)
MIME-Version: 1.0
Sender: jakub.php@gmail.com
In-Reply-To: <551C41F5.2040401@gmail.com>
References: <CAEKnhAHjM2RY+Z2iB7D5wAb=FA43vMkKb1+34O-rTsuV222YUg@mail.gmail.com>
	<551B9704.4030302@gmail.com>
	<CAEKnhAEjGKLR3iEREywj79X7n7fM=agL69PbR4oTpUvpTW6BgA@mail.gmail.com>
	<551C41F5.2040401@gmail.com>
Date: Fri, 10 Apr 2015 17:16:55 +0100
Message-ID: <CAEKnhAHCLbLiYsG6v3kQxNhERhTEqAho6_V8EOCXc+LOCF2_2g@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec51f9887c54e4e051361179e
Subject: Re: [PHP-DEV] JSON float number as string
From: bukka@php.net (Jakub Zelenka)

--bcaec51f9887c54e4e051361179e
Content-Type: text/plain; charset=UTF-8

Hi,

After bit of thinking I realised that it will be better to go with RFC and
created an initial draft https://wiki.php.net/rfc/json_numeric_as_string .
The thing that there are users asking for similar functionality for ints
which is a bit controversial so it's better to have a RFC for that and also
let people decide about the proposed version. Please don't comment on it
till I put it under discussion (it's not completed yet).

On Wed, Apr 1, 2015 at 8:07 PM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> > 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'd have encoder to ignore it.


I will add a voting options for that to the prepared RFC.


> > 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.
>
> It's not actually a bug - as I said, nobody who knows anything about how
> computers do numbers expects exact representation of floats. That said,
> ability to *somehow* accept numbers which don't fit current precision
> may be useful in some corner cases, especially when you are
> interoperating with systems with different number sizes. As the old
> principle goes, be liberal in what you accept and conservative in what
> you produce. json_decode() option would fit this principle well.
>
>
I still think that this is not just a useful feature. The thing is that a
user has no way to get complete information from the supplied json. The
json is valid for any float value (there are no limits on precision in the
spec) and we don't allow to keep that information. That's a problem and it
doesn't matter if we call it a bug or something else!

Cheers

Jakub

--bcaec51f9887c54e4e051361179e--