PR 287 - added use_keys argument to array_filter() [Discussion]

Another alternative might be to go with a third argument to array_filter(),
but make that an integer with ORable constants ARRAY_FILTER_KEY,
ARRAY_FILTER_VAL - only one of them set calls with a single argument, both
set call with two arguments.

That look like a fairly decent compromise of all the suggestions so far.

var_dump(array_filter(['foo', '', 'bar'], 'strlen', true));

Warning: strlen() expects exactly 1 parameter, 2 given in - on line 1

Not only do we trigger the error handler (a large enough array causes a
performance issue), but we also get back an empty array as a result.
That's
BC and performance loss that's simply unacceptable, so defaulting the
behavior to pass the key is simply out of the question.

Existing code won't pass that third, true, argument to array_filter(), and
thus will not break.

Of course not, the premise was that this would be the result if there was
no third argument and the function would pass the key to the callback by
default (in response to the comment above about removing the third
argument).

Nevertheless, I'd say go with a new array_filter_key() function, because
that permits using existing one-parameter functions like that strlen as a
callback, instead of forcing two-parameter callback functions.

The current patch does not force the callback to take two arguments. By
default the existing behavior is maintained since the third argument is
false by default. I still don't hear a good argument for adding a new
function.

Another alternative might be to go with a third argument to
array_filter(), but make that an integer with ORable constants
ARRAY_FILTER_KEY, ARRAY_FILTER_VAL - only one of them set calls with a
single argument, both set call with two arguments.

I would agree that this is a better solution than the existing patch allows
since the function name does not suggest the filtering of a key or
otherwise. In that case it would be easy to use bit-wise operators to get
both the key and the element into the callback or just one or the other.
The default would be ARRAY_FILTER_VAL, obviously.

I suppose the order of the elements should remain $value, $key in the event
of ARRAY_FILTER_KEY | ARRAY_FILTER_VAL.

best regards
Patrick

var_dump(array_filter(['foo', '', 'bar'], 'strlen', true));

Warning: strlen() expects exactly 1 parameter, 2 given in - on line 1

Not only do we trigger the error handler (a large enough array causes a
performance issue), but we also get back an empty array as a result. That's
BC and performance loss that's simply unacceptable, so defaulting the
behavior to pass the key is simply out of the question.

Existing code won't pass that third, true, argument to array_filter(), and thus will not break.

Nevertheless, I'd say go with a new array_filter_key() function, because that permits using existing one-parameter functions like that strlen as a callback, instead of forcing two-parameter callback functions.

I've mirrored the behaviour of this feature from JavaScript as much as possible (but obviously without passing the array itself as the third argument). As such I don't feel there's a need to introduce yet another function just so that the key is passed as the first argument. And to use both key and value forces the developer to use closures instead of just any callback unless this means the second argument passed to the callback is the array :)

Another alternative might be to go with a third argument to array_filter(), but make that an integer with ORable constants ARRAY_FILTER_KEY, ARRAY_FILTER_VAL - only one of them set calls with a single argument, both set call with two arguments.

I see some potential here, albeit a bit more magical :) Let's see how the discussion progresses.

best regards
Patrick