ICU documentation:
http://icu-project.org/apiref/icu4c/uchar_8h.html#a36982efc84143b9bb5a11bf54b86af48
Currently the PHP function returns the U_NO_NUMERIC_VALUE constant, which
is set to the very weird "float(-123456789)"; basically it's a value that
it's certain it doesn't have an Unicode numeric character equivalent
counterpart.
I would change the function to return NULL instead; what do you think?
ICU documentation:
http://icu-project.org/apiref/icu4c/uchar_8h.html#a36982efc84143b9bb5a11bf54b86af48Currently the PHP function returns the U_NO_NUMERIC_VALUE constant, which
is set to the very weird "float(-123456789)"; basically it's a value that
it's certain it doesn't have an Unicode numeric character equivalent
counterpart.I would change the function to return
NULLinstead; what do you think?
Why is comparing to U_NO_NUMERIC_VALUE undesirable?
Hi!
ICU documentation:
http://icu-project.org/apiref/icu4c/uchar_8h.html#a36982efc84143b9bb5a11bf54b86af48Currently the PHP function returns the U_NO_NUMERIC_VALUE constant, which
is set to the very weird "float(-123456789)"; basically it's a value that
it's certain it doesn't have an Unicode numeric character equivalent
counterpart.I would change the function to return
NULLinstead; what do you think?
While the exact value of U_NO_NUMERIC_VALUE looks weird, nobody is going
to use it directly, you'd be using U_NO_NUMERIC_VALUE. Comparing to it
doesn't look wrong. So changing that to null doesn't seem to improve
much, just introduce incompatibility with ICU.
--
Stas Malyshev
smalyshev@gmail.com
Hi
I would change the function to return
NULLinstead; what do you think?While the exact value of U_NO_NUMERIC_VALUE looks weird, nobody is going
to use it directly, you'd be using U_NO_NUMERIC_VALUE. Comparing to it
doesn't look wrong. So changing that to null doesn't seem to improve
much, just introduce incompatibility with ICU.
personally, I think null (or even false) is better because it's of a
different type (and falsy) and thus more likely to get noticed that
something is wrong. In PHP, you're used to checking for null or false.
Having to deal with values that look like they are within valid ranges
and which also validate to something true-ish is needlessly difficult
and unexpected.
The unicode standard apparently wants to use NaN, so ICU is already
deviating from the standard.
Philip
On Thu, Jul 9, 2015 at 2:09 PM, Philip Hofstetter
phofstetter@sensational.ch wrote:
Hi
I would change the function to return
NULLinstead; what do you think?While the exact value of U_NO_NUMERIC_VALUE looks weird, nobody is going
to use it directly, you'd be using U_NO_NUMERIC_VALUE. Comparing to it
doesn't look wrong. So changing that to null doesn't seem to improve
much, just introduce incompatibility with ICU.personally, I think null (or even false) is better because it's of a
different type (and falsy) and thus more likely to get noticed that
something is wrong. In PHP, you're used to checking for null or false.Having to deal with values that look like they are within valid ranges
and which also validate to something true-ish is needlessly difficult
and unexpected.The unicode standard apparently wants to use NaN, so ICU is already
deviating from the standard.
Right. As I prefer APIs matching PHP common APIs signature the intl
extension followed another goal or design. It matches ICU APIs as much
as possible to make it easy to learn for people already using in other
languages. To me this goal made sense back then. However I do not know
many users actually using ICU in other languages. I am not a fan of
the current situation but changing one part or another to better fit
PHP will be inconsistent.
I am all for a more PHP friendly API tho'. We failed to have so far,
uString bailed out and other attempts did not even remotely get a
consensus. But I still have hope to get something better for the core
unicode features.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org