On Wed, Jul 29, 2015 at 11:09 AM, Yasuo Ohgaki <[email protected]> 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 <[email protected]> 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 <[email protected]>
> >> 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