Re: Adding "numeric" type hint

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