Re: PR 287 - added use_keys argument to array_filter() [Discussion]
| From: | Sherif Ramadan | Date: | Tue, 18 Jun 2013 16:38:25 +0000 |
| Subject: | Re: PR 287 - added use_keys argument to array_filter() [Discussion] | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-67722@lists.php.net to get a copy of this message | ||
On Tue, Jun 18, 2013 at 11:27 AM, Leigh <leight@gmail.com> wrote:
> On 18 June 2013 00:20, Sherif Ramadan <theanomaly.is@gmail.com> wrote:
>
>> I'm starting up a thread for discussion on Pull Request 287
>> https://github.com/php/php-src/pull/287 (allowing array
>> keys to be passed
>> to the callback function of array_filter through a third optional boolean
>> argument).
>>
>
> Why not use array_filter_keys?
>
>
That actually isn't a bad idea. I would consider going that route if this
patch presents any real world problems that could be better solved with
introducing a new function. I just don't see any reason for a new function
now given that this patch does not present any BC and can still solve the
same problem without adding a new function.
> There are many other array functions that work with keys using this naming
> pattern. This would make it clearer in the code what is being filtered, and
> no need for the additional parameter.
>
>
The problem with having one callback for just the keys and another for the
array elements is that you're stuck in a situation where you can't possibly
use both. We have that problem with array sort functions that allow a user
defined callback. For example, we have usort and uksort, but there is no
sort function that can offer both. It's plausible that a user may be
relying on both in certain cases (for a example a map of maps).
> In this case I think I would still prefer it if the callback took a single
> parameter. Values can still be easily looked up with $array[$key] in user
> defined callbacks, but all of the built-in functions that take a single
> parameter are still available to use.
>
I would like to solve the problem without introducing new problems. If I
can do that we get PHP to take a step forward and not a step side-ways.