Req #68456 [Com]: json_decode should be able to treat all numbers as strings

From: Date: Sun, 19 Apr 2015 19:32:18 +0000
Subject: Req #68456 [Com]: json_decode should be able to treat all numbers as strings
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-192208@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=68456&edit=1 ID: 68456 Comment by: admin at bittylicious dot com 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: 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. Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2015-03-15 18:16:55] bukka@php.net The problem is that the precision will be lost anyway. Most of all you loose the precision immediately when you save it as a float. Basically this: $a = 1234567890.12345678; will loose the precision. You will be never able to get it back. I hope that this example will explain it a bit more: http://3v4l.org/r2uGa Mind that string conversion in json would do the same thing as using (string). Otherwise it wouldn't respect precision ini. Can you see what I mean now? ------------------------------------------------------------------------ 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

« previous php.bugs (#192208) next »