Variadic is_*() functions

5 years ago by Woortmann — view source

unread

Hi internals,

as I reviewed a bunch of code for handling data from different sources
(eg. json) in the last days I stumbled over code like this multiple times:

if (!(is_numeric($input['example1']) && is_numeric($input['example2']))) {

if (!is_numeric($input['example1'] || !is_numeric($input['example2'])) {

and I had multiple problems with this.

it's kinda hard to read
multiple writings for the same logic
ends up in complex conditionals

I searched for discussions regarding this topic and found it was
mentioned in a 'side thread' of the RFC for changing empty() to a
variadic a few years ago (https://externals.io/message/82549#82641) and
I'd like to collect some feedback if it's wothy to revisit the topic to
write the above example as:

if (!is_numeric($input['example1'], $input['example2'])) {

Except the is_callable() method all is_*() methods could be extended
with a variadic behaviour which would check the given values from the
left to the right and abort if a value doesn't match the condition (in
the example if a given value is not numeric). So all in all there are
some points to talk about: Revisit the discussion? Which functions are
reasonable to be extended? If all functions are reasonable: what to do
with is_callable()?

regards,
Enno

5 years ago by Levi Morrison — view source

unread

Hi internals,

as I reviewed a bunch of code for handling data from different sources
(eg. json) in the last days I stumbled over code like this multiple times:

if (!(is_numeric($input['example1']) && is_numeric($input['example2']))) {

if (!is_numeric($input['example1'] || !is_numeric($input['example2'])) {

and I had multiple problems with this.

it's kinda hard to read

multiple writings for the same logic

ends up in complex conditionals

I searched for discussions regarding this topic and found it was
mentioned in a 'side thread' of the RFC for changing empty() to a
variadic a few years ago (https://externals.io/message/82549#82641) and
I'd like to collect some feedback if it's wothy to revisit the topic to
write the above example as:

if (!is_numeric($input['example1'], $input['example2'])) {

Except the is_callable() method all is_*() methods could be extended
with a variadic behaviour which would check the given values from the
left to the right and abort if a value doesn't match the condition (in
the example if a given value is not numeric). So all in all there are
some points to talk about: Revisit the discussion? Which functions are
reasonable to be extended? If all functions are reasonable: what to do
with is_callable()?

regards,
Enno

--

My position is the same: pushing the variadic behavior into the
functions means that each function needs to pick || or &&
behavior, both of which are useful. I would rather see more
descriptive function names, such as all_of or any_of:

if (!all_of('is_numeric', [$input['example1'],

$input['example2']])) {/.../}

These do not need to be part of PHP core, but perhaps they could be.

I recognize that there is one downside, which is that lazy evaluation
is lost, but generally don't see it to be an issue in these specific
cases.

5 years ago by Chase Peeler — view source

unread

On Mon, Feb 11, 2019 at 8:39 AM Woortmann, Enno enno.woortmann@web.de
wrote:

Hi internals,

as I reviewed a bunch of code for handling data from different sources
(eg. json) in the last days I stumbled over code like this multiple
times:

if (!(is_numeric($input['example1']) && is_numeric($input['example2'])))
{

if (!is_numeric($input['example1'] || !is_numeric($input['example2'])) {

and I had multiple problems with this.

it's kinda hard to read

multiple writings for the same logic

ends up in complex conditionals

I searched for discussions regarding this topic and found it was
mentioned in a 'side thread' of the RFC for changing empty() to a
variadic a few years ago (https://externals.io/message/82549#82641) and
I'd like to collect some feedback if it's wothy to revisit the topic to
write the above example as:

if (!is_numeric($input['example1'], $input['example2'])) {

Except the is_callable() method all is_*() methods could be extended
with a variadic behaviour which would check the given values from the
left to the right and abort if a value doesn't match the condition (in
the example if a given value is not numeric). So all in all there are
some points to talk about: Revisit the discussion? Which functions are
reasonable to be extended? If all functions are reasonable: what to do
with is_callable()?

regards,
Enno

--

My position is the same: pushing the variadic behavior into the
functions means that each function needs to pick || or &&
behavior, both of which are useful. I would rather see more
descriptive function names, such as all_of or any_of:
if (!all_of('is_numeric', [$input['example1'],
$input['example2']])) {/.../}

These do not need to be part of PHP core, but perhaps they could be.

I recognize that there is one downside, which is that lazy evaluation
is lost, but generally don't see it to be an issue in these specific
cases.

Lazy evaluation doesn't have to be lost if the all_of and any_of functions
are written correctly. all_of will return false as soon as one of them
fails, and any_of will return true as soon as one of them passes.
<?php

function all_of($callback,...$params){
foreach($params as $param){
if(!$callback($param)){
return false;
}
}
return true;
}

function any_of($callback,...$params){
foreach($params as $param){
if($callback($param)){
return true;
}
}
return false;
}

Unless you are talking about cases like this:
if(is_numeric(reallyFastFunc($foo)) || is_numeric(reallySlowFunc($bar)))
In that case, you might be able to short circuit the evaluation of
reallySlowFunc($bar), which wouldn't be the case with
if(any_of('is_numeric',reallyFastFunc($foo),reallySlowFunc($bar))){}

However, at that point, I'd say that
1.) If performance isn't an issue, break those function calls out and make
your code more readable:
$f1 = reallyFastFunc($foo);
$f2 = reallySlowFunc($bar);
if(any_of('is_numeric',$f1,$f2)){}
2.) If performance is an issue, fall back to the old method
if(is_numeric(reallyFastFunc($foo)) || is_numeric(reallySlowFunc($bar))){}

--

--
-- Chase
chasepeeler@gmail.com

5 years ago by Levi Morrison — view source

unread

I recognize that there is one downside, which is that lazy evaluation
is lost, but generally don't see it to be an issue in these specific
cases.

Lazy evaluation doesn't have to be lost if the all_of and any_of functions are written correctly. all_of will return false as soon as one of them fails, and any_of will return true as soon as one of them passes.

Unless you are talking about cases like this:
if(is_numeric(reallyFastFunc($foo)) || is_numeric(reallySlowFunc($bar)))
In that case, you might be able to short circuit the evaluation of reallySlowFunc($bar), which wouldn't be the case with
if(any_of('is_numeric',reallyFastFunc($foo),reallySlowFunc($bar))){}

Yes, this is what I was referring to. As previously stated, I don't
think it's likely to be an issue. If it is, then as you stated the
normal boolean logic can be used in such places.

In other words, nothing needs to be done in PHP itself. Just write or
use someone else's all_of, any_of, none_of, etc, functions.

5 years ago by Christoph M. Becker — view source

unread

My position is the same: pushing the variadic behavior into the
functions means that each function needs to pick || or &&
behavior, both of which are useful. I would rather see more
descriptive function names, such as all_of or any_of:
if (!all_of('is_numeric', [$input['example1'],
$input['example2']])) {/.../}

These do not need to be part of PHP core, but perhaps they could be.

I recognize that there is one downside, which is that lazy evaluation
is lost, but generally don't see it to be an issue in these specific
cases.

See https://github.com/php/php-src/pull/1385, which has been abanoned,
though.

--
Christoph M. Becker

5 years ago by Chase Peeler — view source

unread

I recognize that there is one downside, which is that lazy evaluation
is lost, but generally don't see it to be an issue in these specific
cases.

Lazy evaluation doesn't have to be lost if the all_of and any_of
functions are written correctly. all_of will return false as soon as one of
them fails, and any_of will return true as soon as one of them passes.

Unless you are talking about cases like this:
if(is_numeric(reallyFastFunc($foo)) || is_numeric(reallySlowFunc($bar)))
In that case, you might be able to short circuit the evaluation of
reallySlowFunc($bar), which wouldn't be the case with
if(any_of('is_numeric',reallyFastFunc($foo),reallySlowFunc($bar))){}

Yes, this is what I was referring to. As previously stated, I don't
think it's likely to be an issue. If it is, then as you stated the
normal boolean logic can be used in such places.

In other words, nothing needs to be done in PHP itself. Just write or
use someone else's all_of, any_of, none_of, etc, functions.

I'm sure there would be performance enhancement by having it handled with
C vs PHP. I would guess you'd probably need to implement separate functions
for each is_* variant though: any_numeric, all_numeric, none_numeric,
any_boolean, all_boolean, none_boolean, etc. You could probably still have
the any_of, all_of, none_of versions as a shortcut though. I'm speaking
from a point of some ignorance though in terms of what is and isn't faster
when done in C.

Whether it needs to be in core/bundled extension is another debate though.
Seems like it might be a good thing for someone wanting to learn to write
extensions to get their feet wet with, though. I did something similar when
I wanted to try out writing an extension. I implemented a left($str,$len)
and right($str,$len) method... which are basically just shortcuts for
substr*.. but gave me some experience with all of the boiler plate needed,
as well as utilizing existing functions.

*left($str,$len) => substr($str,0,$len)
right($str,$len) => substr($str,-$len);

--

--
-- Chase
chasepeeler@gmail.com

5 years ago by Sara Golemon — view source

unread

My position is the same: pushing the variadic behavior into the
functions means that each function needs to pick || or &&
behavior, both of which are useful.

Additionally, I recall from that thread (or a similar one on the same
topic) some pushback on isset() even having behavior like this. That it
should be considered a mistake. Not saying I agree with going so far as to
call it a mistake, but it does seem to have been an less than ideal choice.

I would rather see more
descriptive function names, such as all_of or any_of:

The feels like your C++ experience talking. :D
I do agree though, I think this model gives much more power and
flexibility, I'd also favor such functions taking iterables (as you show in
your examples) over variadic signatures (as shown in some replies) because
this allows the short-circuiting to halt generators early as well.

These do not need to be part of PHP core, but perhaps they could be.

My preference is for the community to build what they want in userspace,
then worry about teaching the engine to optimize the pattern when it sees
it.

-Sara

5 years ago by come@opensides.be — view source

unread

Le lundi 11 février 2019, 08:59:17 CET Levi Morrison a écrit :

My position is the same: pushing the variadic behavior into the
functions means that each function needs to pick || or &&
behavior, both of which are useful. I would rather see more
descriptive function names, such as all_of or any_of:
if (!all_of('is_numeric', [$input['example1'],
$input['example2']])) {/.../}

My first thought was that this must already exists under another name, but it seems that none of array_map, array_walk or array_reduce allows to do that easily.
(That is, in a more readable way than the boolean operator string, otherwise it’s useless)

Côme

5 years ago by Sara Golemon — view source

unread

My first thought was that this must already exists under another name,
but it seems that none of array_map, array_walk or array_reduce allows to
do that easily.
(That is, in a more readable way than the boolean operator string,
otherwise it’s useless)

Not in core, but I and I'm sure others, have built that pattern more than
once.
Ref: https://github.com/phplang/generator/blob/master/src/iterable.php

-Sara