Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86029
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.171 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAObuZduZBM0GyWJMA1Fd7eCgPE4vFFZrrhpREQ50a4QJhG6Nvg@mail.gmail.com>
References: <CAGa2bXYzp3XimLXxC+Py2t1DWhCfX8coTdYHzf6zEiKdxA7r8Q@mail.gmail.com>
 <55401F31.9030703@gmail.com> <CAObuZduZBM0GyWJMA1Fd7eCgPE4vFFZrrhpREQ50a4QJhG6Nvg@mail.gmail.com>
Date: Thu, 30 Apr 2015 06:15:18 +0900
Message-ID: <CAGa2bXar_oXrsPAErNx5BUdkFAy-p8-D0tfhc3pAnDTGBGJJ7Q@mail.gmail.com>
To: Ryan Pallas <derokorian@gmail.com>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113d36be4d0d290514e37c7c
Subject: Re: [PHP-DEV] Adding "numeric" type hint
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a113d36be4d0d290514e37c7c
Content-Type: text/plain; charset=UTF-8

Hi Stas and Ryan,

On Wed, Apr 29, 2015 at 9:33 AM, Ryan Pallas <derokorian@gmail.com> 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.
>>
>> This is exactly what's wrong with strict typing in PHP. However, if you
>> use real numeric string and do not enable strict typing - it works just
>> fine. We don't need more types for this.
>>
>> > There are cases that programmer want/need to handle any numeric values.
>>
>> There also cases when programmer needs to handle Roman numbers, phone
>> numbers, valid XML strings and TCP/IP headers. But we should not add
>> types into the language for those.
>>
>> > 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
>>
>> Typing is not solution for every data restriction, especially not in
>> PHP. If you app needs strings that can not be represented by PHP basic
>> types, you need custom validation code.
>>
>> > 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
>>
>> If you type your parameter, then you declare "I want this to fail if the
>> parameter is not of this type". Then you can't complain when it fails -
>> that's exactly what you asked for.
>>
>
> I agree with Stanislav here, if you want to accept any type of number, its
> easy enough to add your own checking to do that with the wonderful
> is_numeric. And for simplicity, make an invalidArgument method that you can
> call after manually checking if arguments are wrong: *http://3v4l.org/r0qO0
> <http://3v4l.org/r0qO0>* Works for all versions this tool runs as well.
>

The objective to have type "hint" is to remove such checks by users, isn't
it?
Do you really think all users will write such code for database/json/etc
values?

The issue is that weak mode type hint is *not* weak at all. It forces to
have
machine native type rather than it's data form.

PHP apps are easily broken by too large value because PHP stops execution
by fatal error. i.e. DoS became easy. I will never write such code, but I
don't
want to check and fix library that I would like to use. I don't think I can
manage
programmers to do that even if they are under my control.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a113d36be4d0d290514e37c7c--