Re: Two new functions array_first() and array_last()

On Wed, Oct 18, 2023 at 2:49 PM Brandon Jackson <brandonja991@gmail..com> wrote: > > The only portion in your email I disagree with is this ending. I believe > there are enough use-cases where if the first value is "valid null" or > "default null" it won't matter. The developer will treat them both the > same. Perhaps you disagree with this and want to avoid ambiguity at all > costs. My proposal to avoid ambiguity would be throwing an exception > instead of involving the key because involving the key can be a composition > between array_first()* and > array_key_first(). > > > > Although I would prefer the function to throw, I think it will have the > same effect as this key discussion: complicate something that can be > simple. If the developer needs to distinguish between "default null" and > "value null", they are able to do so by running > empty() on the array > prior to asking for array_first(). It's actually better > than a try/catch, > to be honest. > > Sure in many use cases undefined and null can be equivalent, but there > are other use cases and considering the fact that php does not have a > user level "undefined" value. It should at least attempt to not be > ambiguous when possible. Instead of being ambiguous by default, > requiring the user to do additional work to not be ambiguous. > > I do think the method is a great opportunity to avoid ambiguity, > without a huge sacrifice on cost. As you said, throwing an exception > would only further complicate things. Sure an empty check would get > the job done, but again I believe it should not require such > additional logic just to not be ambiguous. > My statement about throwing exceptions is, to me, exactly equivalent to the discussion of $key and $value. I believe being ambiguous is fine in this case. If we collectively decide that ambiguity is unacceptable, then my vote is on Exception over involving $key on array_first(). I would go as far to say that if the only option is to have array_first() returning $key and $value simultaneously, I probably would prefer if array_first() does not get implemented at all. > > * If naming is an issue to you, I'd also be fine with > array_value_first(). > If the rfc does maintain only returning the value > array_value_first() IMO is ideal. > * With array_first being so general, I would think it's only fair that > the naming is reserved for something that touches on multiple parts of > the array. > * If someone did want to open an rfc adding the above functionality > they would have to opt for something like array_first_key_value which > having a group of key/value operator methods array_key_first, > array_first, and > array_first_key_value would be absolutely > atrocious IMO. > * Naming consistency with array_key_first would be nice. For new > comers to the language I think it is a reasonable assumption when you > see array_key_first being used. That array_value_first should also > exist that does the same thing for values, and array_first might be a > slight curve ball. > * They are going to do some googling and probably be pointed to some > outdated way of doing things, like using array slice or back to > array_key_first. As time goes on blogs and other places like stack > overflow will update there solutions, and or people will re-ask hoping > there's a more up to date/efficient solution, and hopefully then > someone will actually provide the latest answer of array_first. > Everything you mention about function naming I believe gets invalidated by Larry's comment regarding all of PHP array_() function family. They don't have value in their name when working with array values and they have key when working with array keys. With that, array_first() cannot be "consistent" with array_key_first() without being inconsistent with dozens of PHP array functions. Larry's comment is enough to close down the discussion on the function name as there's no room for anything other than array_first() in my opinion. -- Marco Deleu