Re: json_decode/encode should return full precision values by default
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.
Regards,
--
Yasuo Ohgaki
[email protected]
Thread (24 messages)