Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87094
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGKNXQGqq2s0mfWzYKdnyDrf0ELoDf_Xe3yamxvs4d5yhbDkfw@mail.gmail.com>
References: <CAOv67gvxRZ0e7RBKbSsnZdGz4YDCbE8jNm4ULat4+A3vus7z8Q@mail.gmail.com>
	<559D7DE1.8000603@gmail.com>
	<CAGKNXQGqq2s0mfWzYKdnyDrf0ELoDf_Xe3yamxvs4d5yhbDkfw@mail.gmail.com>
Date: Fri, 10 Jul 2015 12:00:20 +0700
Message-ID: <CAEZPtU75zZeZK-TTH_Lwv_m=pPxFtJ+Ag3UP5Kenf5TP8BDmrg@mail.gmail.com>
To: Philip Hofstetter <phofstetter@sensational.ch>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, Net Mo <netmo.php@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Change IntlChar::getNumericValue() to return something
 less horrible when the char is not numeric?
From: pierre.php@gmail.com (Pierre Joye)

On Thu, Jul 9, 2015 at 2:09 PM, Philip Hofstetter
<phofstetter@sensational.ch> wrote:
> Hi
>
> On Wed, Jul 8, 2015 at 9:45 PM, Stanislav Malyshev <smalyshev@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