On Wed, 26 May 2010 23:30:27 +0100, Derick Rethans <der...@php.net> wrote:
On Wed, 26 May 2010, Davey Shafik wrote:
Would it be possible to support two syntaxes:
function foo( (int) $bar) { } // auto-cast to int
function foo(int $bar) { } // require int
I think that's a brilliant plan. We won't ever agree on whether we want
either strict type hinting, or casting typehinting and this provides
both possibilities with the following pros:
I don't think this compromise is a good idea because, even not considering
whether it's advisable to add this new syntax, it does not cover the weak
direction advocated by Zeev et al.
Let's call this proposal what it is -- strict typing. The auto-cast is (1)
mere fog in this discussion and (2) useless.
(1) fog
function foo( (int) $bar) {}
foo($bar);
is exactly the same, with strict typing, as
function foo(int $bar) { }
foo( (int) $bar);
Do we need a new syntax for this?
(2) useless
Auto-cast offers no form of validation; it just converts possibly invalid
data. If the application has a bug and is passing "abc" to foo, the
programmer will not be alerted. On the contrary, removing the auto-cast
could help the programmer find the bug because the argument could find its
way into an internal function that expected an int, and which would then
emit a notice and fail.
- The syntax is consistent for casting. We already support (int) $bar
anywhere else.
Since it's just a cast, I think it's the bare minimum it has a syntax
consistent with casting.
- The syntax is consistent for strict type checking. We already support
throwing errors with foo(ClassName $bar).
True, but we could also say that weak typing is consistent with the
current syntax for objects (I'm not going to reiterate the argument). In
fact, none of the two is perfectly symmetric; with objects we're checking
an inheritance hierarchy, the strict type checking you defend checks the
zval type (not that I find it relevant).
- There are no new conversion rules that can confuse people.
Weak typing could be aligned with zend_parse_parameters and hence we'd
have no new conversion rules.
- Type checking with "int $bar" will stay fast, as we only have to
compare type.
This is in fact a good argument for strict typing.
First, I'm assuming that in the weak type version, if the function asks
for an int, it ends up receiving an int, even if a conversion and probably
a copy of the zval have to be made. More on that later.
But let's say the PHP programmer receives a string and must pass it to a
function that accepts an "int $bar".
- With strict typing, the user must validate the string, convert it to an
int and pass it. In fact, he MUST do it.
- With weak typing:
- The user may also validate the string, convert it to an int and pass
it. There is no performance penalty with respect to the strict version
because the type check matches.
- The user may validate the string and pass it. When he calls the
function, the string must be checked for numeric validity again and then
(save for pass-by-reference) copied into an int. There is fact a
performance penalty, but it is avoidable and the program works without the
programmer worrying about types.
Now, I assumed passing a variable of a different type forces a
conversion/copy. Is this necessary? Why not pass the original zval? I see
these scenarios:
- The function foo manipulates $bar in a way that would force it to be
converted to an int anyway (say, compares it to an int, sums it,
whatever). In this case, the conversion/copy would have to be done anyway,
so the option is indifferent.
- The function foo passes $bar to an internal function that expects an int
(one or more times). In this case, some memory may have been wasted by
coping the zval, but at least the string is validated as a number only
once -- when foo is called, and not every time the internal function is
called.
- The function foo manipulates $bar in a way that behaves differently
whether it's a numeric string or an int (e.g. bitwise operators). In that
case, the conversion was vital for correctness. Thanks to Derick for
pointing me these cases wherein a numeric string and an int don't behave
similarly.
- The function foo ends up converting the int into a string. In that case,
the conversion/copy was detrimental to performance.
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
