Hi Jakub, For me, JSON is one of a data exchange format just like serialize/var_export. Anyway, we are about to reach an agreement.
On Wed, Jul 29, 2015 at 5:32 PM, Jakub Zelenka <bu...@php.net> wrote: > > >> >>> >>>> Question is "Is this the way it should be?". >>>> >>>> >>> I have already said that using precision ini wasn't the best idea. >>> However json_encode is not the same as serialize and we should not ever >>> change its output in a bug fixing release. Doing that could cause also >>> other issues as this is a BC break. Lets imagine that someone set low >>> precision on purpose just to limit precision and save some space >>> >> >> I've been fixed var_export precision issue as a bug. >> >> [yohgaki@dev php-src]$ git show 3cf2682083fc1c8635b02c4c >> commit 3cf2682083fc1c8635b02c4cf77bdf12c5e5da35 >> Merge: 5c89d5a 4c45e95 >> Author: Yasuo Ohgaki <yohg...@php.net> >> Date: Tue Oct 29 17:30:58 2013 +0900 >> >> Merge branch 'PHP-5.5' >> >> * PHP-5.5: >> Fixed Bug 64760 var_export() does not use full precision for >> floating-point numbers >> >> > Again it's not the same. json_encode is much more used the var_export IMHO > so the chance that you break someone's code is much bigger. Also it doesn't > mean that you did the right thing and it's not a precedence for such change > in json. I guess that there wasn't anyone who would disagree with you at > that time. > I agree that JSON is used more than var_export or even serialize. I guess almost all users do not care much about preciseness of JSON numeric. I was the one also until I had to deal with float values. Since almost nobody cares about preciseness, why not make it more precise? I may ask general list see if there are users who mind this change. > >> Although I don't strongly insist merging fix to 5.6 branch, I think data >> exchange function >> that is not trying to be precise is bad thing. >> >> >>> when transferring data . If you change it, then it's screwed up because >>> it will use different ini. We don't know what people do in their code and >>> we should not break it. As I said this is not a bug but we could consider >>> changing that if the RFC proposing such change passes. >>> >> >> Strong json numeric validator may have problem with the change. However, >> JSON RFC states >> >> 6. Numbers >> This specification allows implementations to set limits on the range >> and precision of numbers accepted. Since software that implements >> IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is >> generally available and widely used, good interoperability can be >> achieved by implementations that expect no more precision or range >> than these provide, in the sense that implementations will >> approximate JSON numbers within the expected precision. A JSON >> number such as 1E400 or 3.141592653589793238462643383279 may indicate >> potential interoperability problems, since it suggests that the >> software that created it expects receiving software to have greater >> capabilities for numeric magnitude and precision than is widely >> available. >> >> Note that when such software is used, numbers that are integers and >> are in the range [-(2**53)+1, (2**53)-1] are interoperable in the >> sense that implementations will agree exactly on their numeric >> values. >> https://tools.ietf.org/html/rfc7159 >> >> In order PHP to be more compatible, we should use IEEE 754 range or >> our other data exchange standard, which is serialize_precision=17. >> >> > We are still compatible. This is recommendation, not requirement. However > I have to agree that it will be probably good idea to change default. But > just only if agreed in RFC as this is not a bug! Personally I am against > changing that to serialize_precision. I'd much prefer introducing new ini > (e.g. json_precision) with the same default as serialize_precision. It > would give more flexibility and allow changing value just for json. > I agree that it is implementation matter how "JSON number" is treated. Since PHP is general programming language, I think it's better to make it as generic as possible by default. It's perfectly OK for me to have json_precision. I prefer to have it indeed! My position is >> - PHP7.0: We must use serialize_precision for JSON >> - PHP5.6: I strongly suggest to use serialize_precision for JSON >> >> > I'd prefer 7.1 as this is not something that would be so urgent. > I guess your reason to postpone the change is "json_precision". This could be done by 7.0 as the resolution requires a trivial change to code. I don't see reasons not to fix this issue for 5.6 if "serialize_precision" is used. As you see we don't agree here. It means that if you want to get it in, > please write RFC. You can add the version option as I did it for json > numeric to string RFC and you will see if others agree with you that this > is a bug. > No problem. I'll start RFC discussion shortly. BTW, please don't care if this is a bug or not. We have lots of issues to be resolved. Let's concentrate resolving issues. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
