Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86041
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.174 as permitted sender)
Message-ID: <55416849.9010808@gmail.com>
Date: Wed, 29 Apr 2015 16:24:57 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Yasuo Ohgaki <yohgaki@ohgaki.net>, Ryan Pallas <derokorian@gmail.com>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <CAGa2bXYzp3XimLXxC+Py2t1DWhCfX8coTdYHzf6zEiKdxA7r8Q@mail.gmail.com> <55401F31.9030703@gmail.com> <CAObuZduZBM0GyWJMA1Fd7eCgPE4vFFZrrhpREQ50a4QJhG6Nvg@mail.gmail.com> <CAGa2bXar_oXrsPAErNx5BUdkFAy-p8-D0tfhc3pAnDTGBGJJ7Q@mail.gmail.com>
In-Reply-To: <CAGa2bXar_oXrsPAErNx5BUdkFAy-p8-D0tfhc3pAnDTGBGJJ7Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Adding "numeric" type hint
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> The objective to have type "hint" is to remove such checks by users,
> isn't it?

No, not really. The objective is to ensure type of the parameter. If you
checks are not limited to types, then typing is not going to help, and I
don't think inventing special built-in type for each narrow use case is
a good way to go.

> Do you really think all users will write such code for database/json/etc
> values?

No, I don't think all users need such checks. But those that do will
have to write the code for it.

> 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 types are not machine native types. But yes, it forces PHP type -
that's why it is *type* check.

> 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

That is a different issue. If you don't want fatal error, a) we have
proposal to make those exceptions, b) it is not fixed by introducing
pseudo-types for narrow use cases, since it is a completely different
issue.

> 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.

You are saying type checking which produces fatal errors does not match
your use case. OK, I can sympathize, but how introducing more
pseudo-types helps? You just fix one narrow use case that you have right
now while leaving the problem still in the same place. That's not a good
way to address it.
-- 
Stas Malyshev
smalyshev@gmail.com