On Wed, Jul 29, 2015 at 11:09 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> 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. > Instead of continuing to use serialize_precision, which will produce unnecessarily long outputs for many values, why don't we just switch to using the 0 mode of zend_dtoa, i.e. to return the shortest output that is still accurate if interpreted in round-to-nearest. I think this is what everybody else is using when they convert floating point numbers to strings. I guess we may not be able to change normal floating point printing to use this, but this seems like the best mode for anything using serialize_precision now and everything that should be using it (like JSON, and queries, etc). Nikita
