On Wed, Oct 18, 2023 at 4:31 AM Robert Landers <landers.rob...@gmail.com>
wrote:

> On Wed, Oct 18, 2023 at 5:26 AM Deleu <deleu...@gmail.com> wrote:
> >
> > On Tue, Oct 17, 2023 at 3:43 PM Brandon Jackson <brandonja...@gmail.com>
> > wrote:
> >
> > > > There is also a technique to make the return value `[$key => $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 = array_first($array);
> > > $value = $first[1] ?? throw new Exception();
> > >
> > > [,$value] = array_first($array) ?? [null, null];
> > > [,$value] = 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 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]` or
the `array_key(array $array, &$key = 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 every
beginner, mid-level, experienced and most senior PHP developers will work
with PHP arrays on way or another. As such, a basic functionality like this
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 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 will
need most of the time. Personally, I think I'd prefer the function to 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 this email, I'd
rather have the simplest thing possible and let userland fill in the
additional complexities needed.

-- 
Marco Deleu

Reply via email to