Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72417
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <52F675F6.6060800@gmail.com>
References: <CAHMUw2EkBEFnb_Qs1y6xS8AEr6dO48wSAqSWr55W3fRMuumT5Q@mail.gmail.com>
	<CADq_CxrU-nkc-EnBM1T_JQdGfAEAfV8emfKgArsuEZk=LtVBTQ@mail.gmail.com>
	<CAHMUw2G6zeMAcQHDvZL5dWp7jrDQEMQrrCnowYUrCf2fxbo0Ow@mail.gmail.com>
	<52F675F6.6060800@gmail.com>
Date: Sun, 9 Feb 2014 08:04:30 +0800
Message-ID: <CAHMUw2EH7m2mtd5Kwim6gPv6JgcuLx4o-990Ymvir60_+kw1NQ@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1133935c9713f704f1edf7da
Subject: Re: [PHP-DEV] [discussion] add array_usearch()
From: tjerk.meesters@gmail.com (Tjerk Meesters)

--001a1133935c9713f704f1edf7da
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Feb 9, 2014 at 2:22 AM, Rowan Collins <rowan.collins@gmail.com>wrote:

> On 06/02/2014 19:55, Tjerk Meesters wrote:
>
>> Consider the following examples for finding a value in an array:
>>
>> array_search($value, $array, true);
>>
>> current(array_keys($array, $value, true));
>>
>> key(array_filter($array, function($item) use ($value) {
>>      return $item === $value;
>> }));
>>
>> Perhaps I've overlooked one way, but that's already three ways of doing
>> something similar; the difference lies in the memory behaviour, the first
>> being O(1) whereas the other two are O(n).
>>
>
> I was pondering this, and it occurred to me it could actually be cast as
> an application of array_reduce(), except that that function doesn't
> currently provide array keys to the callback function. Assuming a third
> parameter was passed to the callback containing the current key, you could
> define it thus:
>
> function array_usearch($array, $fn) {
>     return array_reduce($array, function(&$result, $value, $key) use ( $fn
> ) {
>         if ( is_null($result) && $fn($value, $key) ) {
>             $result = $key;
>         }
>     });
> }
>
> (The invert flag would make it a little more verbose, but this would be
> enough for parity with array_filter() anyway.)
>
> This would presumably have the same memory profile as a dedicated
> implementation (no array needs to be initialised, only the single return
> value), and the same worst-case time performance, but without the ability
> to short-cut once a match has been found.


> Incidentally, in your proposal, you mentioned this:
>
>
>  [2] the array key is passed as the 2nd argument by using
>> `ARRAY_USEARCH_USE_KEY`
>>
>
> Is there a particular reason *not* to pass an extra parameter to
> callbacks, even if it's unused?
>

Yeah, internal functions don't like extra parameters, e.g.:

  is_numeric('123', 4);

  > Warning: is_numeric() expects exactly 1 parameter, 2 given in php shell
code on line 1

This would get in the way when you want to express "give the array key of
the first numeric element".


> In the case of an existing function like array_filter(), I can see that
> there is a small risk of a BC break if a function was reused as the
> callback that could optionally take an additional parameter, and relied on
> that parameter not being passed in, but that seems like a bit of an edge
> case anyway, and doesn't apply to a brand new function.
>
>
> Of couse, the proposed function can trivially be implemented with a
> foreach loop as well, even including a short-cut once a match has been
> found:
>
> function array_usearch( $array, $fn ) {
>     foreach ( $array as $k => $v ) {
>         if ( $fn($k, $v) ) {
>             return $k;
>         }
>     }
>     return false;
> }
>

Right; I would personally prefer this over the rather intricate use of
`array_reduce()` ;-) that said, `array_search()` and `in_array()` can also
be easily implemented in this fashion.


>
> http://codepad.viper-7.com/YM8LSs
>
> Again, I've omitted the ability to invert the matching, but there are
> plenty of efficient ways of adding that.
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
--
Tjerk

--001a1133935c9713f704f1edf7da--