Hi Markus,
> On 1 Jan 2015, at 11:09, Markus Fischer <mar...@fischer.name> wrote:
>
> 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.
I think it’d be weird to have different syntaxes for scalars and non-scalars.
We already use the syntax the RFC proposes in the PHP manual, and I don’t think
anyone’s confused by it.
I realise that the behaviour of scalar type hints is slightly different from
the hints for complex types, but I think this would just look ugly:
function foo((int) $bar, Foo $baz, (float) $qux);
> 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).
Yes and no. With the exception of hexadecimal numbers in strings, explicit
casts and internal functions follow the same rules for conversion. However, the
validation rules don’t match. Explicit casts never fail, while internal
functions will reject arguments that are non-scalar or don’t fit certain rules.
> 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 can’t say I love that behaviour either. It is, however, our existing
behaviour. I’d rather we be consistent with internal functions.
Thanks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
