Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121392
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> <CAPzBOBOUGcRVAV6hUa8uDFgOXGLChAwRv-ga5R1-cnD39cXEpg@mail.gmail.com>
In-Reply-To: <CAPzBOBOUGcRVAV6hUa8uDFgOXGLChAwRv-ga5R1-cnD39cXEpg@mail.gmail.com>
Date: Wed, 18 Oct 2023 10:19:54 -0300
Message-ID: <CADK1yXJbT_r0B0d6-Xiet7MYpphdk7FuFqtvo23K6WcmVZ4EzA@mail.gmail.com>
To: Robert Landers <landers.robert@gmail.com>
Cc: Brandon Jackson <brandonja991@gmail.com>, Saki Takamachi <saki@sakiot.com>, 
	Levi Morrison via internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e036a10607fd80d6"
Subject: Re: [PHP-DEV] Two new functions array_first() and array_last()
From: deleugyn@gmail.com (Deleu)

--000000000000e036a10607fd80d6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 18, 2023 at 9:29=E2=80=AFAM Robert Landers <landers.robert@gmai=
l.com>
wrote:

> 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@=
gmail.com>
> wrote:
> >>
> >> On Wed, Oct 18, 2023 at 5:26=E2=80=AFAM Deleu <deleugyn@gmail.com> wro=
te:
> >> >
> >> > 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>
> $value]`
> >> > > instead of just a value, but this loses simplicity.
> >> > >
> >> > > Hmm, since the naming array_first and array_last doesn't clarify
> that
> >> > > 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
> other. Each function is self-sufficient and independent. Maybe on your
> personal bubble you might need to always keep them next to each other,
> which is why I suggested creating your own userland function that returns
> key and value 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
> Fibers to be a corner (a fraction) of PHP compared to non-Fibers PHP.
> Although Fibers took the approach to not "paint" [what color is] your
> function, it doesn't mean that Fibers can be used without taking
> precaution, as with any 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 o=
wn
> >> > 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]`
> or the `array_key(array $array, &$key =3D null) ` makes it at least 2
> approaches 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 requires to focus first on the most basic aspect of it. Literally eve=
ry
> beginner, mid-level, experienced and most senior PHP developers will work
> with PHP arrays on way or another. As such, a basic functionality like th=
is
> should remain as basic as possible. If needed, PHP can port more helper
> functions into the core to cater for Fibers in the future.
> >
> > In my opinion, the only problem is the ambiguity of returning `null`
> which might mean the array is empty or might mean the first value is trul=
y
> null. If we get a warning box on PHP Docs recommending people to pair thi=
s
> with `empty()` before using it, it gives users coverage for everything th=
ey
> will need most of the time. Personally, I think I'd prefer the function t=
o
> throw an exception than to return `null` when array is empty to avoid
> ambiguity and force folks to use `empty()`, but that would also mean
> complicating the function more due to edge cases, which as I stated in th=
is
> email, I'd rather have the simplest thing possible and let userland fill =
in
> the additional complexities needed.
> >
> > --
> > Marco Deleu
>
> Hey Marco,
>
> > I might be completely wrong here, but on my personal bubble, I consider
> Fibers 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.
>

I completely understand what you're saying and I don't disagree with the
thought process. What I disagree with is your statement that you will
always use array_first() together with array_key_first(). When talking
about standard lists (indexed from 0 to upper-bound), array_first() is an
order of magnitude more useful than array_key_first() as we always know
what the first key is: 0.

Here's another thought process: suppose PHP never gets array_first(). In
your Fiber scenarios, you need to use `array_key_first()` and
`$array[array_key_first()]` and deal with any edge cases around this. You
have found issues, dealt with it and you're now aware of them. It's really
nice that you want to avoid others from going through the same pain as you
did, but the fact is `array_first()` or `$array[0]` is not only ALWAYS used
together with needing to know the key or not ALWAYS used with Fibers.

What I'm saying is: don't force a design functionality only for your use
case, especially as basic and fundamental as PHP Arrays. I don't want to be
forced to write `[$value, $_] =3D array_first()` just because there's a
corner of PHP functionality that needs special treatment. If this was
fibers_array_first() I wouldn't mind at all.

> Keeping them separate only looks "simpler" if you only consider
first-order effects.

Keeping them together only makes sense if you disregard first-order
effects. By "first-order effects" I read "basic functionality" and this is
where our disagreement relies. I wouldn't want PHP to provide the most
basic functionality you can do in an array with a thought process that
disregards the most basic usage.

--=20
Marco Deleu

--000000000000e036a10607fd80d6--