Edit report at https://bugs.php.net/bug.php?id=68456&edit=1
ID: 68456
Updated by: yohgaki@php.net
Reported by: admin at bittylicious dot com
Summary: json_decode should be able to treat all numbers as
strings
Status: Re-Opened
Type: Feature/Change Request
Package: JSON related
Operating System: Linux Wheezy
PHP Version: 5.4.35
Assigned To: bukka
Block user comment: N
Private report: N
New Comment:
Related bug
https://bugs.php.net/bug.php?id=69422
Previous Comments:
------------------------------------------------------------------------
[2015-04-19 19:32:17] admin at bittylicious dot com
Thanks for discussing this on the mailing list - good to hear there are some positive comments too.
I still think this, simpler version should be implemented. We already have JSON_BIGINT_AS_STRING so
it seems as though it could be argued as plugging a missing option rather than a full on enhancement
as such. Going the whole hog and allowing object hints etc., is far larger than this; having this
fix go in means that users can implement "casting" to objects manually, but I have no even
remotely-nice workaround I can use to handle these float values at all at present.
------------------------------------------------------------------------
[2015-04-19 19:09:26] bukka@php.net
Just a quick update. We had a discussion about it on internal list: http://bit.ly/1D2ZyAR . I also started RFC to propose addition of
float and int to string flags: https://wiki.php.net/rfc/json_numeric_as_string
.
However I have been thinking about that a lot and I don't think it would be a proper way how to
fix this. Such flag would influence all float values and it's limited only to string.
I think that better solution would be to introduce support for json schema validation that could be
also extended as a sort of type hints for supplied json. Then it would be possible to select just
specific values and use whatever types (e.g. objects or string). It's a relativaly bigger
feature so it might take a bit longer but I think that it's a proper way of fixing this.
------------------------------------------------------------------------
[2015-03-15 21:17:21] admin at bittylicious dot com
Fab stuff, thanks so much for examining this. Great to hear that the encode functionality is also
under consideration too.
------------------------------------------------------------------------
[2015-03-15 20:06:28] bukka@php.net
That makes sense. I'm a bit dump so it took me a bit... :)
I actually recently closed something similar for encode so the constant could be used in both ways.
I'd imagine something like JSON_DOUBLE_TO_STRING . I'll try to put together a quick RFC
for 5.6 up (with choice for 7 only) next week and if it gets in, I will do the patch.
------------------------------------------------------------------------
[2015-03-15 19:42:53] admin at bittylicious dot com
I do understand what you're saying, but my feature request is under the assumption you never
ever need to convert this to a float, and my real life use case is indeed this situation.
Simplifying things, let's imagine a JSON service that simply multiplies a number by two. You
would pass in:
{"val":1234567890.12345678}
But you would have no way to even pass this to bcmul (which I believe works on strings) without
losing precision even if bcmul needn't have any precision issues.
Consider another service. This simply forwards "val" onwards perhaps with a hash signature
or something. Consider this a "signing service". It cannot read this 'val' value
without losing precision, when I think it should be possible to interpret this as a string. This is
actually more similar to my use case, in other words, using JSON really as a transport mechanism and
not manipulating these numbers within the PHP script.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=68456
--
Edit this bug report at https://bugs.php.net/bug.php?id=68456&edit=1