On 18 September 2013 12:15, Igor Wiedler <i...@wiedler.ch> wrote:
>
> for is_* functions, this could easily be done with a higher-order "every"
> function. You pass a predicate and an array of values. It returns a boolean.
>
> Example:
>
> if (!every('is_int', $numbers)) {
> throw new \InvalidArgumentException(...);
> }
>
> Not only is that much cleaner in my opinion, it also is composable without
> having to change *all* of the is_* predicates.
Might just be me, but I don't really like having function names as
strings (obviously I use it when I _have_ to, but I try and stay away
from it otherwise).
Feedback I'm really interested in is what issues could arise from
changing those predicates. I'm pretty short sighted in this regard,
and mainly see the benefits I would gain from this change, so looking
for more "This is a terrible idea because..." kind of stuff.
On 18 September 2013 13:21, Frank Liepert <frank.liep...@gmx.de> wrote:
>
> Returning bool in this case will make it impossible to respond with a
> meaningful error message. Which of the provided arguments !is_int()?
I agree that it doesn't fit every case, and it's not supposed to. The
same can be said of isset(), if it is important to know which argument
was not set, then you have to use multiple calls.
On 18 September 2013 13:21, Frank Liepert <frank.liep...@gmx.de> wrote:
>
> Finally, the imho best solution would still be introducing optional scalar
> type hinting. But that is another topic and shouldn't be discussed here.
I agree, (both that it would be better, and that it is another topic
entirely - one which usually goes in circles, so lets stay away from
it here :))
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
