Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86153
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.173 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAGa2bXYzp3XimLXxC+Py2t1DWhCfX8coTdYHzf6zEiKdxA7r8Q@mail.gmail.com>
References: <CAGa2bXYzp3XimLXxC+Py2t1DWhCfX8coTdYHzf6zEiKdxA7r8Q@mail.gmail.com>
Date: Mon, 11 May 2015 16:20:39 +0900
Message-ID: <CAGa2bXbs+MsDBYQdiWsG6uX9ZuBd+tstn65V3LK_+mkL+FMTqg@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113d219472752b0515c939e3
Subject: Re: Adding "numeric" type hint
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a113d219472752b0515c939e3
Content-Type: text/plain; charset=UTF-8

Hi all,

On Wed, Apr 29, 2015 at 8:50 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> External data can have any form of numbers.
> Current PHP can handle them as "string". However PHP7's type hint cannot
> handle numeric data well because it only has "int" and "float" hints.
>
> http://3v4l.org/6J0bZ
>
> There are cases that programmer want/need to handle any numeric values.
> e.g. JSON numeric, Database numeric, PHP's array key beyonds INT min/max,
> Values for BCMath/GMP, etc. It's common for 32 bit platforms. For example,
> we cannot do query database safely with "int" type hint.
>
> e.g.
> function get_some_db_record(int $id) {}
>
> Most databases uses 64 bit signed int for database IDs, but this code
> limits
> $id to 32 bit signed int for 32 bit platforms. There are databases that
> allow
> unsigned 64 bit int ID.
>
> To avoid this problem, users must use "string" type hint and have to
> validate
> parameter by themselves. This ruins benefits of type hint. Most PHP will
> not
> use "string" type hint even if apps need large numbers.
>
> How about have "numeric" type hint that accepts any format/class(GMP)
> of numeric values?
>
> function foo(numeric $var) { // do something useful with numeric value }
>
> To be honest, I would like to have StrictSTH RFC behavior for weak mode
> int/float type hints to make sure "int"/"float" has integer/float
> form/value always,
> but "numeric" type hint may do the job. One function with "int"/"float"
> type hint
> could break app with current type hint implementation, though. i.e.
> Working
> app suddenly emits fatal error and exits when database/json returns value
> beyond int/float.
>
> http://3v4l.org/6J0bZ (See how it works with large string integer value)
>
> Any comments?
>

I've never wrote my blog in English, but I wrote one because peice by piece
discussion is not going to anywhere.

http://blog.ohgaki.net/dont-use-php7-type-hint-for-external-data

How many of you think current scalar type hint is useful enough to interact
with database/json/xml/yaml/rest/etc? We need "numeric" hint at least. IMHO.

If not, we need "large warning sign" in documentation as a last resort at
least.

Regards,

P.S. We may be better to declare 32 bit CPU support EOL by PHP 7 to reduce
the impact. We'll have the same issue when 128 bit CPU or 128 bits IEEE 754
float
became in common, though.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a113d219472752b0515c939e3--