Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121383
MIME-Version: 1.0
References: <173ca550-71a0-4bd4-96f2-b64b6155115a@app.fastmail.com>
 <CBB83C7D-B10F-410E-B879-F2FA9EDB2F65@sakiot.com> <CAB_ngDi2bEWYxWF+XMmGHXty5hH44=DepdisOQX9hcGLmz0w9A@mail.gmail.com>
 <CADK1yXLJWo7NJdBGVbtGEeDjRfc1f1LbftgdoP3co_D6d8nz5w@mail.gmail.com>
 <CAPzBOBO=_WODT0HC0uaJ3OvqxD4YuMXqL5a-4tiH+MZAk1TUNQ@mail.gmail.com> <CADK1yXLNz9Qugut4i723TyEbhO0ntWXac=kaUKMMo_a+0piaGQ@mail.gmail.com>
In-Reply-To: <CADK1yXLNz9Qugut4i723TyEbhO0ntWXac=kaUKMMo_a+0piaGQ@mail.gmail.com>
Date: Wed, 18 Oct 2023 14:29:00 +0200
Message-ID: <CAPzBOBOUGcRVAV6hUa8uDFgOXGLChAwRv-ga5R1-cnD39cXEpg@mail.gmail.com>
To: Deleu <deleugyn@gmail.com>
Cc: Brandon Jackson <brandonja991@gmail.com>, Saki Takamachi <saki@sakiot.com>, 
	Levi Morrison via internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Two new functions array_first() and array_last()
From: landers.robert@gmail.com (Robert Landers)

On Wed, Oct 18, 2023 at 1:43=E2=80=AFPM Deleu <deleugyn@gmail.com> wrote:
>
>
>
> On Wed, Oct 18, 2023 at 4:31=E2=80=AFAM Robert Landers <landers.robert@gm=
ail.com> wrote:
>>
>> On Wed, Oct 18, 2023 at 5:26=E2=80=AFAM Deleu <deleugyn@gmail.com> wrote=
:
>> >
>> > On Tue, Oct 17, 2023 at 3:43=E2=80=AFPM Brandon Jackson <brandonja991@=
gmail.com>
>> > wrote:
>> >
>> > > > There is also a technique to make the return value `[$key =3D> $va=
lue]`
>> > > instead of just a value, but this loses simplicity.
>> > >
>> > > Hmm, since the naming array_first and array_last doesn't clarify tha=
t
>> > > it's returning a key or a value. What if it returned both as ?[key,
>> > > value].
>> > >
>> > > That opens quite a few use possibilities:
>> > > $first =3D array_first($array);
>> > > $value =3D $first[1] ?? throw new Exception();
>> > >
>> > > [,$value] =3D array_first($array) ?? [null, null];
>> > > [,$value] =3D array_first($array) ?? throw new Exception();
>>
>>
>> Hey Marco,
>>
>> > This function signature can be accomplished by userland once we have
>> > `array_key_first()` and `array_first()`.
>>
>> This would always mean you have to keep them right next to each other,
>> it would be a best practice to do so and to split them up should be a
>> code smell in any static analysis.
>
>
> "You" (general you) don't always have to keep them right next to each oth=
er. Each function is self-sufficient and independent. Maybe on your persona=
l bubble you might need to always keep them next to each other, which is wh=
y I suggested creating your own userland function that returns key and valu=
e together.
>
>>
>> There is no way to tell if a Fiber
>> is involved in any function call in PHP, thus if you split them apart
>> and call a function, it is possible that your current Fiber is
>> suspended and another Fiber mutates the variable you are referencing
>> (this is especially true in Classes, not so much in pure functions).
>
>
> I might be completely wrong here, but on my personal bubble, I consider F=
ibers to be a corner (a fraction) of PHP compared to non-Fibers PHP. Althou=
gh Fibers took the approach to not "paint" [what color is] your function, i=
t doesn't mean that Fibers can be used without taking precaution, as with a=
ny new tool.
>
>>
>> Since they would always have to be right next to each other, it is
>> easier to just combine them into a single atomic function call, which
>> would negate the need for static analysis to be involved or surprises.
>>
>> > It's much better to keep
>> > `array_first()` as simple as possible and let everyone build their own
>> > approach to go about it since we have so many approaches.
>>
>> There is only one right approach that prevents Fibers from messing up
>> your day, and it would be considerable boilerplate code that you'd
>> have to type every time, as well as involve static analysis and watch
>> for "people who don't know" better in code reviews.
>
>
> You say only one approach, but a return signature of `: [$key, $value]` o=
r the `array_key(array $array, &$key =3D null) ` makes it at least 2 approa=
ches that would be fibers-safe, no?
>
> This is a discussion about an extremely basic functionality that PHP hasn=
't introduced up until now. I think it's an extremely great addition, but r=
equires to focus first on the most basic aspect of it. Literally every begi=
nner, mid-level, experienced and most senior PHP developers will work with =
PHP arrays on way or another. As such, a basic functionality like this shou=
ld remain as basic as possible. If needed, PHP can port more helper functio=
ns into the core to cater for Fibers in the future.
>
> In my opinion, the only problem is the ambiguity of returning `null` whic=
h might mean the array is empty or might mean the first value is truly null=
. If we get a warning box on PHP Docs recommending people to pair this with=
 `empty()` before using it, it gives users coverage for everything they wil=
l need most of the time. Personally, I think I'd prefer the function to thr=
ow an exception than to return `null` when array is empty to avoid ambiguit=
y and force folks to use `empty()`, but that would also mean complicating t=
he function more due to edge cases, which as I stated in this email, I'd ra=
ther have the simplest thing possible and let userland fill in the addition=
al complexities needed.
>
> --
> Marco Deleu

Hey Marco,

> I might be completely wrong here, but on my personal bubble, I consider F=
ibers to be a corner (a fraction) of PHP compared to non-Fibers

Fibers are part of PHP and are being used in more and more libraries.
You may be using them and be totally unaware that you are using them.
I'm not saying we need to "cater" to them, per se, but adding two new
functions that will (most likely) be used on the same data structure,
at nearly the same time, is just asking for devs to get bit by a
concurrency bug. Maybe not this year, or anytime relatively soon, but
eventually, as Fibers and async PHP becomes more popular.

IMHO, it just makes sense to combine them into a single function
(however that looks like). You sidestep a whole class of bugs, and
documentation/education issues, and make the whole world a tiny bit
more reliable. Keeping them separate only looks "simpler" if you only
consider first-order effects.

That's all I'm saying.