On 2010-05-27, at 8:14 PM, Zeev Suraski wrote:
> At 13:59 27/05/2010, Ilia Alshanetsky wrote:
>> Zeev,
>>
>> Auto-conversion does not validate input to the function/method, it merely
>> obfuscates the "wrong" input by converting it to desired type resulting in a
>> potentially un-expected value. I must say I am completely against the
>> auto-conversion hint idea.
>
> All of PHP is built on that kind of conversion. See Brian Moon's email for a
> detailed instructions.
> 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.
Is a 'scalar' typehint still being considered? It doesn't seem to suffer from
the conversion vs. typechecking argument.
As far as this discussion goes, I would want to add the following:
function f(array $a) {
}
f(1234);
f(new StdClass);
Currently both throw:
"Catchable fatal error: Argument 1 passed to f() must be an array, integer
given"
IMHO it would be inconsistent with the language to let an 'int' typehint behave
in any way different.
The way I see it, one end of the discussion proposes:
function f(int $i) {
}
as an alternative to:
function f($i) {
$i = (int)$i;
}
While the other end as an alternative to:
function f($i) {
if (!is_int($i)) trigger_error(..etc..);
}
The first mainly just saves a few characters, (or introduces a whole new type
conversion table), while the second provides
* a consistent way to communicate incorrectly typed arguments.
* strict argument passing, making it easier to spot mistakes earlier in the
development process.
While you can disagree the world needs strict typing in PHP, I find it hard to
believe the 'conversion syntax sugar' is really considered.
Evert
P.S.: The last thing I want is add more noise to the discussion. Consider
emailing me off-list if you want to respond to this.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
