On Tue, Jun 18, 2013 at 1:04 PM, Patrick Schaaf <b...@bof.de> wrote: > > > 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 >
