On Wed, Oct 18, 2023 at 1:43 PM Deleu <deleu...@gmail.com> wrote: > > > > 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
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
