Hi,
The voting is now open:
FWIW, I voted no to all of them because (as you even say in the RFC),
this is probably better be solved with a JSON schema thingy.
cheers,
Derick
Hi Derick,
Hi,
The voting is now open:
FWIW, I voted no to all of them because (as you even say in the RFC),
this is probably better be solved with a JSON schema thingy.
JSON Schema does not help to decoding/encoding numeric data without loosing
data.
JSON Schema Core
http://json-schema.org/latest/json-schema-core.html#anchor8
Note: JSON specification does not specify precision. So number could be any
number.
JSON Schema Validation
http://json-schema.org/latest/json-schema-validation.html#anchor5
Those who do not care rounding errors/etc, they can use default behavior.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi,
The voting is now open:
FWIW, I voted no to all of them because (as you even say in the RFC),
this is probably better be solved with a JSON schema thingy.JSON Schema does not help to decoding/encoding numeric data without
loosing data.JSON Schema Core
http://json-schema.org/latest/json-schema-core.html#anchor8
Note: JSON specification does not specify precision. So number could be
any number.JSON Schema Validation
http://json-schema.org/latest/json-schema-validation.html#anchor5Those who do not care rounding errors/etc, they can use default behavior.
JSON Schema could be used to encode huge numbers correctly, so I would like
to have it in the future also.
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Yasuo,
Hi Derick,
Hi,
The voting is now open:
FWIW, I voted no to all of them because (as you even say in the RFC),
this is probably better be solved with a JSON schema thingy.JSON Schema does not help to decoding/encoding numeric data without
loosing data.JSON Schema Core
http://json-schema.org/latest/json-schema-core.html#anchor8
Note: JSON specification does not specify precision. So number could be
any number.JSON Schema Validation
http://json-schema.org/latest/json-schema-validation.html#anchor5Those who do not care rounding errors/etc, they can use default behavior.
The idea would be to use JSON schema just for selecting the type for
deserialized item in decoded JSON. It means that you could for example
select one float item that you want to decode as a string but other floats
would be still decoded as floats. That gives a better flexibility and helps
the problem in the same way. Please see my email to Alexey when we
discussed this RFC (there are few examples):
internals@lists.php.net/msg78698.html" rel="nofollow" target="_blank">https://www.mail-archive.com/internals@lists.php.net/msg78698.html
Cheers
Jakub
Hi Jakub,
The idea would be to use JSON schema just for selecting the type for
deserialized item in decoded JSON. It means that you could for example
select one float item that you want to decode as a string but other floats
would be still decoded as floats. That gives a better flexibility and helps
the problem in the same way. Please see my email to Alexey when we
discussed this RFC (there are few examples):internals@lists.php.net/msg78698.html" rel="nofollow" target="_blank">https://www.mail-archive.com/internals@lists.php.net/msg78698.html
Thank you for the reply.
This could be done, but requires more work just to get raw value out of
JSON.
So I vote "yes" for all because your RFC is feasible resolution and useful
enough.
As I wrote in somewhere in discussion, it was better if all values are
decoded as
string just like DB values. Encoding is headache, though..
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Guys
It was state that JSON scheme will take some time to be implement
and probably wouldn't be able for 5.6. IMHO JSON_FLOAT_AS_STRING
probably it isn't the idle fix (the idle solution would be to not even have
a bug/error like this),
so the question would be, do we want developers decoding json with
precision loss until JSON scheme
eventually comes or give them the ability
to decide for them self on how to proceed.
+1
Pasindu
Hi Yasuo,
Hi Derick,
Hi,
The voting is now open:
FWIW, I voted no to all of them because (as you even say in the RFC),
this is probably better be solved with a JSON schema thingy.JSON Schema does not help to decoding/encoding numeric data without
loosing data.JSON Schema Core
http://json-schema.org/latest/json-schema-core.html#anchor8
Note: JSON specification does not specify precision. So number could be
any number.JSON Schema Validation
http://json-schema.org/latest/json-schema-validation.html#anchor5Those who do not care rounding errors/etc, they can use default behavior.
The idea would be to use JSON schema just for selecting the type for
deserialized item in decoded JSON. It means that you could for example
select one float item that you want to decode as a string but other floats
would be still decoded as floats. That gives a better flexibility and helps
the problem in the same way. Please see my email to Alexey when we
discussed this RFC (there are few examples):internals@lists.php.net/msg78698.html" rel="nofollow" target="_blank">https://www.mail-archive.com/internals@lists.php.net/msg78698.html
Cheers
Jakub
--
Pasindu De Silvappasindud@gmail.com ppasindud@gmail.com
JSON Schema Core
http://json-schema.org/latest/json-schema-core.html#anchor8
Note: JSON specification does not specify precision. So number could be any
number.
This is my own problem with most of these recent developments. Simply
switching from a 32 bit to 64 bit truncation would probably be workable
since it seems 32bit systems are no longer to be supported, but not
having any provision for precision just seems totally wrong?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Le 09/06/2015 20:23, Jakub Zelenka a écrit :
The voting is now open:
Hi,
Discussing this RFC with other people at AFUP, we would, by a small
margin, also be on the -1 side (for all 4 points).
Still, if this was to pass, we would be +1 for PHP 7.1 ; and -1 for PHP
5.6 and 7.0.
Thanks!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
Martin, I am guessing it's the same reason as Derick?.
On Wed, Jun 17, 2015 at 12:39 AM, Pascal MARTIN, AFUP <
mailing@pascal-martin.fr> wrote:
Le 09/06/2015 20:23, Jakub Zelenka a écrit :
The voting is now open:
Hi,
Discussing this RFC with other people at AFUP, we would, by a small
margin, also be on the -1 side (for all 4 points).Still, if this was to pass, we would be +1 for PHP 7.1 ; and -1 for PHP
5.6 and 7.0.Thanks!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/--
--
Pasindu De Silvappasindud@gmail.com ppasindud@gmail.com
Hi
The voting is now open:
The RFC has been rejected (all 4 proposed options).
The bug https://bugs.php.net/bug.php?id=68456 (proposing such flag for
float decoding) will be closed as "Won't fix" because the result shows that
this is not the right way how to tackle the problem. The json shema has
already its feature request ( https://bugs.php.net/bug.php?id=69422 ) and
should be the way going forward in my opinion.
Cheers
Jakub
Hi Jakub,
The voting is now open:
The RFC has been rejected (all 4 proposed options).
The bug https://bugs.php.net/bug.php?id=68456 (proposing such flag for
float decoding) will be closed as "Won't fix" because the result shows that
this is not the right way how to tackle the problem. The json shema has
already its feature request ( https://bugs.php.net/bug.php?id=69422 ) and
should be the way going forward in my opinion.
It requires a lot more codes to make it work (both user and PHP), but
it seems it's the only way to retrieve "correct raw value". Looking forward
the patch.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net