At 15:31 27/05/2010, Richard Quadling wrote:
On 27 May 2010 12:14, Zeev Suraski <z...@zend.com> wrote:
> BTW - even if strict type checking was implemented, do you truly think
> people won't simply cast their inputs to make PHP shutup about "42" not
> being a valid int? Â Let me assure you, they
would. Â You'd gain nothing - as
> a matter of fact you'd lose out a bit since "abc" strings or arrays will
> happily cast into (int), while with our proposed solution - they won't.
But it would be the user making that choice though.
We're leading him to that choice with strong type
checking. We shouldn't fool ourselves.
Rather than the
developer having to handle the incorrectly typed value.
That's just plain wrong. As far as the
developer's concerned, there isn't *ANY*
difference from strict type checking. In both
cases, what he'll get is the value he asked
for. A function expecting an 'int' will ALWAYS
receive an int (that is, a zval that's
IS_LONG). For the user, auto-converting type
hints are much more lax and consistent with the
rest of PHP's scalar type behaviors, but as far
as the API developer's concerned, the contract is identical.
As I see it, it is no difference than interfaces.
A class with interface X has to implement whatever methods interface X
declares. Failure to do so results in fatal errors. And rightly so.
A function with prototype (int $a, bool $b, string $c) has to be
supplied the correctly typed data to work. Why is that so wrong?
Except scalar types are interchangeable in PHP
(sure, not in 100.0% of the places, only
99.9%). If you rather think about scalars as
objects, imagine they all have __toString(),
__toInt() methods - except they're implemented in
the most fundamental foundations of the language.
Do we accept objects that have a __toString()
method in strictly-typed string arguments? If not, why not?
In any decent course regarding defensive programming, we are told to
filter input and escape output. One easy way of filtering input is to
cast and verify.
Once cast and verified we know we've got the right type and acceptable values.
With the proposed solution, we do the casting for
the user - which in itself is a nice protection
layer. If additional verification is necessary -
a great place to put it in would be the function
itself. Neither approaches force the user to do verification.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
