Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:87364 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 87533 invoked from network); 29 Jul 2015 09:10:37 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Jul 2015 09:10:37 -0000 Authentication-Results: pb1.pair.com header.from=yohgaki@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=yohgaki@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.170 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.160.170 mail-yk0-f170.google.com Received: from [209.85.160.170] ([209.85.160.170:33046] helo=mail-yk0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7A/50-20105-C8898B55 for ; Wed, 29 Jul 2015 05:10:36 -0400 Received: by ykba194 with SMTP id a194so2673740ykb.0 for ; Wed, 29 Jul 2015 02:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=gnO+kjMa+ULLNOqIgf4gmvjuz/4Mit0ZT/J9cnR1lxQ=; b=037q4bY2scm2Ia9OQPMlPyh63n707udkebGfEycdq8cKjU00qOTjnNMQtQ2X7txYXb KojidQJq+y3d3zc3IWgci/oG4GuooEsSoc86EjI/PHYmAO7gutaRCIxoq8j1P+Xnkic7 rDHlv95mjmfr0qIdytdL9kkP4tRgDE5mdtgQkdwn6duiMXE6F7tf+6oRWg/1zJozmPVF pXllDMGj/hnYJ1rwhd9TEN/ISlPkoQOXZUE4ymSaGJXbwihGH67BHP60FhI4K6my8xZZ x8o7dLXpe6TvAdBcfbS6RsRqy0YbkcB3WdCFnY0ps80PdJmujQ6THCtSa0mC2p4VwCzf H4iw== X-Received: by 10.170.162.6 with SMTP id e6mr42547925ykd.64.1438161032675; Wed, 29 Jul 2015 02:10:32 -0700 (PDT) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.129.40.77 with HTTP; Wed, 29 Jul 2015 02:09:53 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Jul 2015 18:09:53 +0900 X-Google-Sender-Auth: 1hLKX6TYvEVObMqRxKpNyHuxlrs Message-ID: To: Jakub Zelenka Cc: Anthony Ferrara , "internals@lists.php.net" Content-Type: multipart/alternative; boundary=001a11390cf27b89b3051bfff5ca Subject: Re: [PHP-DEV] json_decode/encode should return full precision values by default From: yohgaki@ohgaki.net (Yasuo Ohgaki) --001a11390cf27b89b3051bfff5ca Content-Type: text/plain; charset=UTF-8 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 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 >> 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 yohgaki@ohgaki.net --001a11390cf27b89b3051bfff5ca--