On Thu, Jul 9, 2015 at 2:09 PM, Philip Hofstetter <phofstet...@sensational.ch> wrote: > Hi > > On Wed, Jul 8, 2015 at 9:45 PM, Stanislav Malyshev <smalys...@gmail.com> > wrote: >>> I would change the function to return NULL instead; 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
