Re: Re:[VOTE] array_key_first(),array_key_last(), array_value_first(),array_value_last()
| From: | Enno Woortmann | Date: | Wed, 11 Jul 2018 19:07:51 +0000 |
| Subject: | Re: Re:[VOTE] array_key_first(),array_key_last(), array_value_first(),array_value_last() | ||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-102773@lists.php.net to get a copy of this message | ||
Am 11.07.2018 um 20:18 schrieb Levi Morrison:
With the problem I didn't aim at the problem this RFC tries to solve. I think everyone participating in the discussions in the mailing list understood the problem of non efficient userland implementations. I aimed at the issue which lead to the gap between our implementation approaches: the indistinguishability between a correct function call which returns null and an invalid call with either an empty array or a non array value. As this is an existing problem I still think we should find a common solution (which can't be part of this RFC's scope) instead of bringing up new function signature patterns for new functions.In my opinion neither rejecting the RFC nor changing it to return tuples solves the underlying problem.What is the underlying problem in your opinion? My opinion is that the core problem is that these functions cannot be efficiently implemented in userland, at least not the ones that get the last key and/or value of the array. You either need to make a copy or traverse through the whole array.