2012/3/8 John Crenshaw <johncrens...@priacta.com>:
> From: Arvids Godjuks [mailto:arvids.godj...@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 with
>> such mechanic because it already exists. Consistency, man, consistency :)
>
> Yeah, I was a huge advocate of this too until recently. I've changed my mind
> though, ironically enough to ensure better consistency.
>
> PHP since 5.3 gives an E_WARNING if you pass poorly-converting scalar data 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 good
> argument for E_CATCHABLE_FATAL if you pass something retarded (like a
> resource, 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
> functions. This would allow us to repaint the entire proposal as bringing to
> the language level the same level of scalar typing available internally,
> using the same syntax as the docs (which sounds much more reasonable and less
> 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
> providing strings comes into play regardless of whether people validated
> their inputs. For example, if (is_numeric($priority) && $priority >= 0 &&
> $priority <= 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 and
> eventually cause frustrating failures if not handled intelligently. You don't
> have to love it, but basically if you want a typing proposal to have any
> 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 => $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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
