Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102769
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain web.de designates 212.227.17.12 as permitted sender)
To: Levi Morrison <levim@php.net>, Christoph Becker <cmbecker69@gmx.de>
Cc: =?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>
Message-ID: <b5f9cb46-3e1c-14f7-e3a4-c6c4abd03462@web.de>
Date: Wed, 11 Jul 2018 19:42:31 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <CAFMT4Nqt1ZymBdL3YbV69yj-eOPU-RoWC5EONsOhYLjnm-Fpfw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
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 ("Woortmann, Enno")

Am 11.07.2018 um 18:20 schrieb Levi Morrison:

> As an example, it was claimed:
>
>> If I use a function I expect it to give me a return value which I can
>> use without any further post processing $wantedValue =
>> fancyFunction($someInput);
> But this isn't true even for the array_value_* functions. There must
> be pre or post processing because of error conditions. This was
> pointed out by myself and others, but it was still ignored.
>
> This is what I mean by discarded, not discussed.

In my eyes being aware of what I put into a function and thus catching 
non array inputs and empty inputs before differs a lot from post 
processing return values as it increases the comprehensibility of the 
code. I also can think of cases where the input format is known and no 
further checks are required.

Additionally the tuple return pattern is not common among the PHP core 
functions and I don't know many occurences of this pattern in userland 
PHP code neither at the companies I've worked at nor at open source 
software/frameworks (correct me if I'm wrong) except the by far outdated 
old foreach construct with reset() and each(), thus I assume it's not a 
that common pattern for PHP developers to use it in core functions.

As I pointed out during the discussion we should also watch at existing 
functions with the same problem, differ between a valid return value and 
an error.
Not all of them can be changed to use different return mechanisms like 
the tuple return pattern (eg. array_pop).

Maybe we can instead think about changing Z_PARAM_ARRAY_EX in a later 
stage to not return null in error cases but instead throw an 
InvalidArgumentException or something like that (at least for function 
calls with an empty array for functions which require a filled array, 
for invalid types maybe a fatal TypeError like it's thrown when a type 
hinted argument in a userland function is violated is the correct 
choice). Would be a pretty large BC breaking change but it would be 
consistent among the array functions.

In my opinion neither rejecting the RFC nor changing it to return tuples 
solves the underlying problem.