RE: [PHP-DEV] Scalar Type Hints v0.4
| From: | François Laupretre | Date: | Thu, 19 Feb 2015 17:37:00 +0000 |
| Subject: | RE: [PHP-DEV] Scalar Type Hints v0.4 | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-83230@lists.php.net to get a copy of this message | ||
Hi Patrick,
I understand but we cannot include casting rules in the scope. And, while attractive, I think ZPP
and casting cannot share the same ruleset, at least as long as casting is defined as aimed to being
as permissive as possible.
François
De : Patrick ALLAERT [mailto:patrickallaert@php.net]
Envoyé : jeudi 19 février 2015 13:46
À : francois@php.net; Sara Golemon; PHP internals
Objet : Re: [PHP-DEV] Scalar Type Hints v0.4
Le Wed Feb 18 2015 at 19:10:08, François Laupretre <francois@php.net> a écrit :
> De : Patrick ALLAERT [mailto:patrickallaert@php.net]
>
> The biggest advantage, IMHO, is that you get the exact same result whether
> you do:
>
> foo((int) $value);
>
> or:
>
> foo($value);
>
> ... whatever the mode you are in.
Wrong. Parameter parsing rules are much more restrictive than casting rules.
Only 'foo((int)'orange')' would (erroneously) succeed.
Francois, I'm very aware of the distinction between cast mechanism and ZPP, but I obviously
haven't been clear about the fact that the (conversion|coercion|type juggling|...) reporting
configuration I proposed would have to be used in ZPP *AND* casting mechanism (and anywhere else
where some conversion applies).
With:
$value = "foo";
foo((int) $value);
it is: "(int) $value" that would generate a warning/error depending on the reporting, not
while parsing the parameter of function foo(), which would receive an int (0) in this precise case.
And this would address the cases:
http://example.org/foo.php?id=42
http://example.org/foo.php?id=bar
foo.php:
<?php
fetchById(int $id) {
// ...
}
fetchById($_GET["id"]);
even if $_GET["id"] is replaced by (int) $_GET["id"];
Cheers,
Patrick