Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102773
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain web.de designates 212.227.17.11 as permitted sender)
To: Levi Morrison <levim@php.net>
Cc: Christoph Becker <cmbecker69@gmx.de>,
 =?UTF-8?Q?Bj=c3=b6rn_Larsson?= <bjorn.x.larsson@telia.com>, mail@pmmaga.net,
 me@jhdxr.com, internals <internals@lists.php.net>
References: <e8fdd7ca-135a-2a7f-79cd-e45486f4ba8b@web.de>
 <tencent_3910FA2861CB2DDC6DBA9FF9@qq.com>
 <CAJd4=Ybos2TpD5gkBZu3H-ttamojZkDsrNXz8eLyfNgU0bD2Kw@mail.gmail.com>
 <CAFMT4No0iPMOS-BF4QALGNM9HQ7ynEAZr=Og-XH+T0OJxueBQg@mail.gmail.com>
 <13b4eb91-6566-3724-d45d-aa63254e1f58@telia.com>
 <a02bcf08-160a-59d1-a3bc-3ba7460c78bc@gmx.de>
 <CAFMT4Np-sQ4MtGyN_M1t=pEY05gv7QDrUgPO2j3LZKe5G3tCSw@mail.gmail.com>
 <CAFMT4Nqt1ZymBdL3YbV69yj-eOPU-RoWC5EONsOhYLjnm-Fpfw@mail.gmail.com>
 <b5f9cb46-3e1c-14f7-e3a4-c6c4abd03462@web.de>
 <CAFMT4NpWgV8gv7g7xfxL9gb6PsvwVV6-v01vqWwGXrWHpTEE=w@mail.gmail.com>
Message-ID: <4136e73c-6c64-3168-39c5-c574d5a5730e@web.de>
Date: Wed, 11 Jul 2018 21:07:51 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.9.0
MIME-Version: 1.0
In-Reply-To: <CAFMT4NpWgV8gv7g7xfxL9gb6PsvwVV6-v01vqWwGXrWHpTEE=w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(),array_key_last(),
 array_value_first(),array_value_last()
From: enno.woortmann@web.de (Enno Woortmann)

Am 11.07.2018 um 20:18 schrieb Levi Morrison:

>> In my opinion neither rejecting the RFC nor changing it to return tupl=
es
>> solves the underlying problem.
> What is the underlying problem in your opinion?
>
> My opinion is that the core problem is that these functions cannot be
> efficiently implemented in userland, at least not the ones that get
> the last key and/or value of the array. You either need to make a copy
> or traverse through the whole array.

With the problem I didn't aim at the problem this RFC tries to solve. I=20
think everyone participating in the discussions in the mailing list=20
understood the problem of non efficient userland implementations.

I aimed at the issue which lead to the gap between our implementation=20
approaches: the indistinguishability between a correct function call=20
which returns null and an invalid call with either an empty array or a=20
non array value.
As this is an existing problem I still think we should find a common=20
solution (which can't be part of this RFC's scope) instead of bringing=20
up new function signature patterns for new functions.