Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58776
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <A633CF2D7C7BED41B41F1E64F25507B8069DC4723B@MAILR001.mail.lan>
References: <CAJRMtAGqZCWThbZVztGN3-FyQ4MkJAs=uO_V-6pUCy9q2aAaZw@mail.gmail.com>
 <CAKOpQSyas7HSDXD5bftK9o18ucYAfQvxRtTUjYOgRSv_4nY-9A@mail.gmail.com>
 <CAJWj5+EQhhYDTh8DHwv2N4pk8FQybX3P5H292BGixbHSLB7k3A@mail.gmail.com>
 <CAAyV7nGQFrMoneDKvr0s1djOOkjn6rMj6PJcuB0842eA8EefOw@mail.gmail.com>
 <52.38.15021.3A1E65F4@pb1.pair.com> <4F570EBB.6030103@sugarcrm.com>
 <60744d7ea642fe03c7110502a3f4276a@mohiva.com> <CAAyV7nGZdq+TYU3eiQXj5CtEkRs84u_oOXRB7m+RNseU1QtG+Q@mail.gmail.com>
 <CAL0xaBHC8vFSnuezWwWqsBczHZA3uvgpb+K3z3z87Mc2Gbeseg@mail.gmail.com>
 <CAJWj5+HDyBvMGN7HiHBBEswr67s=tEfsTd3mHbzfeAZRrVmB2w@mail.gmail.com>
 <CAL0xaBGAHfOSR1g4meDsJfczBTR0dOfypBjHLXGT7h9o5T7eeA@mail.gmail.com>
 <CAL0xaBHqQkGi+mt0MZ=NPYKmO9PdoCDSFdUF_CukJWaqOuAgqg@mail.gmail.com> <A633CF2D7C7BED41B41F1E64F25507B8069DC4723B@MAILR001.mail.lan>
Date: Thu, 8 Mar 2012 13:05:50 +0200
Message-ID: <CAL0xaBHyHYM3d=45en51fGY4hT-spJmgUdborTHBPmnJT3qErw@mail.gmail.com>
To: John Crenshaw <johncrenshaw@priacta.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Scalar Type Hinting
From: arvids.godjuks@gmail.com (Arvids Godjuks)

2012/3/8 John Crenshaw <johncrenshaw@priacta.com>:
> From: Arvids Godjuks [mailto:arvids.godjuks@gmail.com]
>
>> > I like that. What should we do if this appears? As it's now - just
>> > throw an "Catchable fatal error" and let the script blow-up? I would
>> > go this far.
>>
>> I think "Catchable fatal error should" be fine and users are familiar wi=
th such mechanic because it already exists. Consistency, man, consistency :=
)
>
> Yeah, I was a huge advocate of this too until recently. I've changed my m=
ind though, ironically enough to ensure better consistency.
>
> PHP since 5.3 gives an E_WARNING if you pass poorly-converting scalar dat=
a to an internal function (For example, substr('foo', 'bar');) This changed=
 my mind about the level of error to raise here. I think there's still a go=
od argument for E_CATCHABLE_FATAL if you pass something retarded (like a re=
source, or possibly even an array), but I think we should strive as far as =
possible to be consistent with the behavior of scalars passed to internal f=
unctions. This would allow us to repaint the entire proposal as bringing to=
 the language level the same level of scalar typing available internally, u=
sing the same syntax as the docs (which sounds much more reasonable and les=
s politically charged than "Please add scalar typing...again".)
>
> See Ferenc's reply about 30 seconds ago for more details on this...

Well, it may be that way too, but I have to point out that language
level functions are built in and you can't add or remove a type hint
for them. It expects integer and does it's best to make it an integer,
even if it gives some weird result. And backwards compability is an
issue here - _the_  _main_  _issue_. At the language level you have to
maintain that BC and sure if you make zend_parse_params reject strings
where an in should be without any warning - you sure have a rage storm
on the internet that will crush you to peaces.

Adding optional type hinting isn't bound to that BC, because we have
no scalar type hints at all. In 5.3 they added E_NOTICE and E_WARNING
to zend_parse_params. Are you sure they would not change the E_WARNING
to  E_ERROR in say PHP 6? Or bump E_NOTICE to E_WARNING? What if
type-juggling rules change? If that will happen - you will have your
type hint behavior change between versions and I think that's not
really a good idea.
So from one point of view it's a nice idea to tie that to
zend_param_parse, but from the other side that does not look like a
good idea. Internals of the engine tend to change more often than the
external syntax and behavior.

>
>> > Type hints are meant to
>> > filter input from external sources
>>
>> Correction, it should read like this:
>> Type hints are _not_ meant to filter input from external sources
>
> That's not really the point though. The issues with external sources prov=
iding strings comes into play regardless of whether people validated their =
inputs. For example, if (is_numeric($priority) && $priority >=3D 0 && $prio=
rity <=3D 3) will pass and still leaves you with a string, and that string =
currently works just fine everywhere as if it were an integer. What's more,=
 the folks that will be voting on this have made it clear in the past that =
failure to account for type juggling in any such proposal is a deal breaker=
. For many users these inputs can and will trickle down through the code an=
d eventually cause frustrating failures if not handled intelligently. You d=
on't have to love it, but basically if you want a typing proposal to have a=
ny chance I think you'll have to support it.
>
> John Crenshaw
> Priacta, Inc.

That's why I described the rules when type juggling comes into play.
If you send a string number, it is converted from string to number by
the type hint. If you send a string of characters and pass it to a int
type hinted function - sorry, but it's you who shout yourself with a
shotgun, not someone else.
I have to repeat it again - type hinting is not for converting and
filtering data. It is not meant to be used in code witch deals with
user input.
You will never write a code like this in 5.3 or 5.4
<?php
function processArray(array $data) {
    foreach ($data as $k =3D> $v) {
        // Do something
    }
}

processArray($_POST['some_var']);
?>
Should I tell you why? I think you know. Same goes for hinting
integer, string, float, bool or any other type. To convert data we
have conversion operators and functions like settype. Hints only
should take into account that a validated param can be a number in
string representation and change the type accordingly. But if passed
something different than a number - fail.