> 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.
> Ultimately, there's 2 parallel discussion that somewhat intertwine
> themselves: Fibers ("async" code) and ambiguity ("value null" vs "default
> null") and while there are options that may cater for both of them, there are
> also options that cater only for each of them individually. Trying to
> over-pollute a function as simple as `array_first()` to cater for these edge
> cases is where I think the problem is because userland will always be able to
> tackle these issues by wrapping the basic functionality provided by core.
My argument was purely for ambiguity and the other reasons outlined.
While the possible edge cases from fibers usage arguably may not be a
great primary reason to offer such functionality, it is a great
supporting argument.
> * 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`.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
