Hello Sebastian,
On 01.01.15 09:28, Sebastian Bergmann wrote:
> Am 31.12.2014 um 21:27 schrieb Andrea Faulds:
>> Parameter type hints for PHP’s scalar types
>
> Please use the term "type declaration for arguments" (or "type
> declaration for parameters") instead of "type hints". If it's used
> then it's not a hint.
Thanks for bringing this up.
Interestingly, from the RFC I had another issue with it: what it
technically does it neither "hinting" nor "declaration" but it tries
conversion and seem to have multiple action how it may continue:
- continue, everything as expected
- catchable error
- notices thrown
To Andrea:
As much as I'd like to see such a language feature like this, I think:
1. the naming of the RFC thus the intent is confusing
What it really does is it tries its best to convert, e.g. the RFC reads
as it tries to work like this:
function foo(int $bar) {
$bar = (int)$bar;
}
>From your description I understand that, technically, it doesn't do that
exactly; I was merely trying to make a point how it "looks it works";
see my next point.
2. Casting and Validation Rules
"While this RFC merely follows PHP's existing rules for scalar
parameters, used by extension functions, these rules may not be familiar
to all readers of this RFC."
Very good job in pointing this out! Which brings me to this question:
are these different rules than the general casting rules (as I exampled
above) ? If yes, wouldn't this increase the burden on PHP developers
even more to learn new rules (and, those rules are already to many to
sanely remember).
3. "Non-numeric strings not accepted. Numeric strings with trailing
characters are accepted, but produce a notice. "
That behavior, IMHO, is very bad for this kind of feature.
What's the point of continuing the code when developer asked for "int"
and code logic continues with "something not quite an int"?
Doesn't that defeat the whole purpose of the use of this RFC?
I know that this can be fixed using an error handler, throwing an
exception to abort code execution but that should really be an error
anyway, IMHO, on par with a gross mismatch of types.
I'm not in favor of these soft rules.
thanks,
- Markus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
