Hi again,

On Fri, Jan 16, 2015 at 4:52 PM, Rowan Collins <rowan.coll...@gmail.com> wrote:
>
> Specifically, I don't think a library author should be able to tell me that,
> just because they're feeling picky, '42' and 42 are not equivalent when
> calling their function. It does very little to protect me from genuine
> mistakes (passing completely the wrong parameter), and makes my life as user
> of the library harder.
>

With no attempt to argue, I just thought of another example, inspired
by the ones given in the RFC - it is fairly common for functions
dealing with times to only accept a UNIX timestamp or otherwise just a
single kind of a time unit, such as only a count of minutes or days.

So where '7 years' is passed and and accepted when using a weak hint
(by truncating the trailing non-numeric characters), a strict hint on
the other hand may prevent the input of incorrect data (given that
it's not years that are expected, of course).

While typing that, I thought of another possible improvement that may
be made regardless of strict, weak or no scalar type hints are
implemented. I'm not sure if it's feasible due to the
parser/compiler/whatever possibly not having access to this info, so I
hope that somebody confirms that ...

Can it be made for the error messages to mention the *parameter name*
instead of only its number?

Take the following example:

    function fubar(string $data, int $mode) {}
    fubar('dummy', 'non-integer');

A 'fubar() expects parameter 2 ($mode) to be integer, string given'
would be substantially more useful in case of wrong input.

Cheers,
Andrey.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to