Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87083
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sensational.ch designates 195.226.6.199 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <559D7DE1.8000603@gmail.com>
References: <CAOv67gvxRZ0e7RBKbSsnZdGz4YDCbE8jNm4ULat4+A3vus7z8Q@mail.gmail.com>
 <559D7DE1.8000603@gmail.com>
Date: Thu, 9 Jul 2015 09:09:56 +0200
Message-ID: <CAGKNXQGqq2s0mfWzYKdnyDrf0ELoDf_Xe3yamxvs4d5yhbDkfw@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: 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: phofstetter@sensational.ch (Philip Hofstetter)

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.

Philip