Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] [VOTE] array_key_first(), array_key_last(), array_value_first(), array_value_last()

Posted by Woortmann, Enno 
Hi,

as the discussion got no new contributions I'd like to start the voting
for the RFC fo add new functions for the handling of outer array elements.

https://wiki.php.net/rfc/array_key_first_last

To have a better separation I split up the vote for the functions. The
first vote covers the functions to handle keys: array_key_first() and
array_key_last(). The second vote covers the corresponding functions to
handle the values: array_value_first() and array_value_last().

As this RFC adds functions but doesn't change the language syntax a 50%
+ 1 majority is required for both votes. The votes are open until
2018-07-16.

The discussion for this RFC is located at

https://externals.io/message/102245

Regards,

Enno




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I called for use-cases and practically nobody responds and you put it
to vote, discarding nearly all advice you were given?

-1

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I voted no.
I don't think we have an agreement on dealing with non-existing value, and the way this RFC proposed, just returning null without any notice/warning, is wrong IMO. I know we already do this in other array_* functions, but we cannot keep making mistakes just because we already made same mistake.

Regards,
CHU Zhaowei
Also voting no, and wished I had mailed earlier.

Accessing the keys and values separately is not a good design in my
opinion, as it leads to:

> All four functions either return the requested key/value
> or null if an empty array is provided.

Having what looks likes valid values returned for array_value_first()
and array_value_last()

A think a better pattern would be to return a tuple as Levi suggested.

[$key, $value] = array_first($array);
[$key, $value] = array_last($array);

For people not used to returning tuples.....you should branch out a
bit and try using them.

They are a better pattern to use when returning multiple values from
a function that don't need/deserve their own class/struct creating.

cheers
Dan
Ack


On 9 July 2018 at 18:31, CHU Zhaowei <[email protected]> wrote:
> I voted no.
> I don't think we have an agreement on dealing with non-existing value, and the way this RFC proposed, just returning null without any notice/warning, is wrong IMO. I know we already do this in other array_* functions, but we cannot keep making mistakes just because we already made same mistake.
>
> Regards,
> CHU Zhaowei

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei <[email protected]> wrote:

> I don't think we have an agreement on dealing with non-existing value, and
> the way this RFC proposed, just returning null without any notice/warning,
> is wrong IMO. I know we already do this in other array_* functions, but we
> cannot keep making mistakes just because we already made same mistake.
>

I voted no for the same reason. I'd even say that introducing a new array_
function that still accepts non arrays just to return null with a warning
doesn't make sense at this point.

With that said, I'd gladly vote yes if there would be a way to distinguish
array_value_first([]) from array_value_first([0 => null]).

Regards,
Pedro
On Tue, Jul 10, 2018 at 12:59 PM Pedro Magalhães <[email protected]> wrote:
>
> On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei <[email protected]> wrote:
>
> > I don't think we have an agreement on dealing with non-existing value, and
> > the way this RFC proposed, just returning null without any notice/warning,
> > is wrong IMO. I know we already do this in other array_* functions, but we
> > cannot keep making mistakes just because we already made same mistake.
> >
>
> I voted no for the same reason. I'd even say that introducing a new array_
> function that still accepts non arrays just to return null with a warning
> doesn't make sense at this point.
>
> With that said, I'd gladly vote yes if there would be a way to distinguish
> array_value_first([]) from array_value_first([0 => null]).
>
> Regards,
> Pedro

To safely use it a call to empty or count or something needs to happen:

if (!empty($array)) {
$value = array_value_first($array);
// do something with $value
}

This is okay, but not great. Compare that to the design that returns a
tuple though:

if ([$_, $value] = array_first($array)) {
// do something with $value
}

People who argue against the tuple because they don't like the design
need to consider the bigger picture. The tuple way is less code,
serves more use cases with fewer functions, and I even [implemented
it][1]. If the array destructuring behavior seems unclear we can
simply put an example in the manual pages for these functions --
problem solved.

This is not how RFC feedback should be handled. I hope more people
vote no so we can reject this do it properly.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Tue, Jul 10, 2018 at 6:41 PM Levi Morrison <[email protected]> wrote:
>
> On Tue, Jul 10, 2018 at 12:59 PM Pedro Magalhães <[email protected]> wrote:
> >
> > On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei <[email protected]> wrote:
> >
> > > I don't think we have an agreement on dealing with non-existing value, and
> > > the way this RFC proposed, just returning null without any notice/warning,
> > > is wrong IMO. I know we already do this in other array_* functions, but we
> > > cannot keep making mistakes just because we already made same mistake..
> > >
> >
> > I voted no for the same reason. I'd even say that introducing a new array_
> > function that still accepts non arrays just to return null with a warning
> > doesn't make sense at this point.
> >
> > With that said, I'd gladly vote yes if there would be a way to distinguish
> > array_value_first([]) from array_value_first([0 => null]).
> >
> > Regards,
> > Pedro
>
> To safely use it a call to empty or count or something needs to happen:
>
> if (!empty($array)) {
> $value = array_value_first($array);
> // do something with $value
> }
>
> This is okay, but not great. Compare that to the design that returns a
> tuple though:
>
> if ([$_, $value] = array_first($array)) {
> // do something with $value
> }
>
> People who argue against the tuple because they don't like the design
> need to consider the bigger picture. The tuple way is less code,
> serves more use cases with fewer functions, and I even [implemented
> it][1]. If the array destructuring behavior seems unclear we can
> simply put an example in the manual pages for these functions --
> problem solved.
>
> This is not how RFC feedback should be handled. I hope more people
> vote no so we can reject this do it properly.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
(Sorry for the duplicate message there, got some hotkeys wrong in my client).

Here's the implementation:
https://github.com/php/php-src/compare/master...morrisonlevi:array_first-and-array_last

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Le mardi 10 juillet 2018, 18:41:17 CEST Levi Morrison a écrit :
> People who argue against the tuple because they don't like the design
> need to consider the bigger picture.

My guess is people arguing for the tuple do not understand the usecase :-)

Each time I felt the need for array_first_value was because I was using it on a function return to do something with it.

Like:
if (array_first_value(some_function()) > 3) {
// do something
}

Either I know that the array is not empty, or I do not care because NULL will be ignored correctly.
In the second case, with a tuple I’m stuck because if I do:

if (array_first(some_function())[1] > 3) {
// do something
}

If array_first returns NULL this will trigger a PHP error. So I have to add more code to handle this special case while I do not need any with array_first_value.

Côme
> Either I know that the array is not empty, or I do not care because NULL will be ignored correctly.
> In the second case, with a tuple I’m stuck because if I do:
>
> if (array_first(some_function())[1] > 3) {
> // do something
> }
>
> If array_first returns NULL this will trigger a PHP error. So I have to add more code to handle this special case while I do not need any with array_first_value.

This is true. For completeness the fix is very mild:

if (([$_, $value] = array_first(some_function()) && $value > 3) {
// do something
}

I still think this is better. Forcing you to handle the error case is
not a bad thing.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Den 2018-07-11 kl. 02:41, skrev Levi Morrison:
> On Tue, Jul 10, 2018 at 12:59 PM Pedro Magalhães <[email protected]> wrote:
>> On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei <[email protected]> wrote:
>>
>>> I don't think we have an agreement on dealing with non-existing value, and
>>> the way this RFC proposed, just returning null without any notice/warning,
>>> is wrong IMO. I know we already do this in other array_* functions, but we
>>> cannot keep making mistakes just because we already made same mistake.
>>>
>> I voted no for the same reason. I'd even say that introducing a new array_
>> function that still accepts non arrays just to return null with a warning
>> doesn't make sense at this point.
>>
>> With that said, I'd gladly vote yes if there would be a way to distinguish
>> array_value_first([]) from array_value_first([0 => null]).
>>
>> Regards,
>> Pedro
> To safely use it a call to empty or count or something needs to happen:
>
> if (!empty($array)) {
> $value = array_value_first($array);
> // do something with $value
> }
>
> This is okay, but not great. Compare that to the design that returns a
> tuple though:
>
> if ([$_, $value] = array_first($array)) {
> // do something with $value
> }
>
> People who argue against the tuple because they don't like the design
> need to consider the bigger picture. The tuple way is less code,
> serves more use cases with fewer functions, and I even [implemented
> it][1]. If the array destructuring behavior seems unclear we can
> simply put an example in the manual pages for these functions --
> problem solved.
>
> This is not how RFC feedback should be handled. I hope more people
> vote no so we can reject this do it properly.
>
I do like this approach with two functions array_first & array_last
returning
a tuple. However, voting is  underway and it looks like it will pass.

I wonder what the RFC author (Enno W) thinks about that approach?

r//Björn Larsson

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 11.07.2018 at 17:19, Björn Larsson wrote:

> Den 2018-07-11 kl. 02:41, skrev Levi Morrison:
>
>> On Tue, Jul 10, 2018 at 12:59 PM Pedro Magalhães <[email protected]> wrote:
>>
>>> On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei <[email protected]> wrote:
>>>
>>>> I don't think we have an agreement on dealing with non-existing
>>>> value, and
>>>> the way this RFC proposed, just returning null without any
>>>> notice/warning,
>>>> is wrong IMO. I know we already do this in other array_* functions,
>>>> but we
>>>> cannot keep making mistakes just because we already made same mistake.
>>>>
>>> I voted no for the same reason. I'd even say that introducing a new
>>> array_
>>> function that still accepts non arrays just to return null with a
>>> warning
>>> doesn't make sense at this point.
>>>
>>> With that said, I'd gladly vote yes if there would be a way to
>>> distinguish
>>> array_value_first([]) from array_value_first([0 => null]).
>>>
>>> Regards,
>>> Pedro
>> To safely use it a call to empty or count or something needs to happen:
>>
>>      if (!empty($array)) {
>>          $value = array_value_first($array);
>>          // do something with $value
>>      }
>>
>> This is okay, but not great. Compare that to the design that returns a
>> tuple though:
>>
>>      if ([$_, $value] = array_first($array)) {
>>          // do something with $value
>>      }
>>
>> People who argue against the tuple because they don't like the design
>> need to consider the bigger picture. The tuple way is less code,
>> serves more use cases with fewer functions, and I even [implemented
>> it][1]. If the array destructuring behavior seems unclear we can
>> simply put an example in the manual pages for these functions --
>> problem solved.
>>
>> This is not how RFC feedback should be handled. I hope more people
>> vote no so we can reject this do it properly.
>>
> I do like this approach with two functions array_first & array_last
> returning
> a tuple. However, voting is  underway and it looks like it will pass.
>
> I wonder what the RFC author (Enno W) thinks about that approach?

This already has been discussed weeks ago, see
<https://externals.io/message/102245#102317>;.

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Le mercredi 11 juillet 2018, 07:37:56 CEST Levi Morrison a écrit :
> This is true. For completeness the fix is very mild:
>
> if (([$_, $value] = array_first(some_function()) && $value > 3) {
> // do something
> }
>
> I still think this is better. Forcing you to handle the error case is
> not a bad thing.

The point of these functions is to avoid complicated hard to read code for simple operations.
This if is hard to read for me and not much better that array_values(some_function())[0].

Côme

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Den 2018-07-11 kl. 17:27, skrev Christoph M. Becker:
> On 11.07.2018 at 17:19, Björn Larsson wrote:
>
>> Den 2018-07-11 kl. 02:41, skrev Levi Morrison:
>>
>>> On Tue, Jul 10, 2018 at 12:59 PM Pedro Magalhães <[email protected]> wrote:
>>>
>>>> On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei <[email protected]> wrote:
>>>>
>>>>> I don't think we have an agreement on dealing with non-existing
>>>>> value, and
>>>>> the way this RFC proposed, just returning null without any
>>>>> notice/warning,
>>>>> is wrong IMO. I know we already do this in other array_* functions,
>>>>> but we
>>>>> cannot keep making mistakes just because we already made same mistake.
>>>>>
>>>> I voted no for the same reason. I'd even say that introducing a new
>>>> array_
>>>> function that still accepts non arrays just to return null with a
>>>> warning
>>>> doesn't make sense at this point.
>>>>
>>>> With that said, I'd gladly vote yes if there would be a way to
>>>> distinguish
>>>> array_value_first([]) from array_value_first([0 => null]).
>>>>
>>>> Regards,
>>>> Pedro
>>> To safely use it a call to empty or count or something needs to happen:
>>>
>>>      if (!empty($array)) {
>>>          $value = array_value_first($array);
>>>          // do something with $value
>>>      }
>>>
>>> This is okay, but not great. Compare that to the design that returns a
>>> tuple though:
>>>
>>>      if ([$_, $value] = array_first($array)) {
>>>          // do something with $value
>>>      }
>>>
>>> People who argue against the tuple because they don't like the design
>>> need to consider the bigger picture. The tuple way is less code,
>>> serves more use cases with fewer functions, and I even [implemented
>>> it][1]. If the array destructuring behavior seems unclear we can
>>> simply put an example in the manual pages for these functions --
>>> problem solved.
>>>
>>> This is not how RFC feedback should be handled. I hope more people
>>> vote no so we can reject this do it properly.
>>>
>> I do like this approach with two functions array_first & array_last
>> returning
>> a tuple. However, voting is  underway and it looks like it will pass.
>>
>> I wonder what the RFC author (Enno W) thinks about that approach?
> This already has been discussed weeks ago, see
> <https://externals.io/message/102245#102317>;.
>
Aha, tnx.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, Jul 11, 2018 at 9:27 AM Christoph M. Becker <[email protected]> wrote:
>
> On 11.07.2018 at 17:19, Björn Larsson wrote:
>
> > Den 2018-07-11 kl. 02:41, skrev Levi Morrison:
> >
> >> On Tue, Jul 10, 2018 at 12:59 PM Pedro Magalhães <[email protected]> wrote:
> >>
> >>> On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei <[email protected]> wrote:
> >>>
> >>>> I don't think we have an agreement on dealing with non-existing
> >>>> value, and
> >>>> the way this RFC proposed, just returning null without any
> >>>> notice/warning,
> >>>> is wrong IMO. I know we already do this in other array_* functions,
> >>>> but we
> >>>> cannot keep making mistakes just because we already made same mistake.
> >>>>
> >>> I voted no for the same reason. I'd even say that introducing a new
> >>> array_
> >>> function that still accepts non arrays just to return null with a
> >>> warning
> >>> doesn't make sense at this point.
> >>>
> >>> With that said, I'd gladly vote yes if there would be a way to
> >>> distinguish
> >>> array_value_first([]) from array_value_first([0 => null]).
> >>>
> >>> Regards,
> >>> Pedro
> >> To safely use it a call to empty or count or something needs to happen:
> >>
> >> if (!empty($array)) {
> >> $value = array_value_first($array);
> >> // do something with $value
> >> }
> >>
> >> This is okay, but not great. Compare that to the design that returns a
> >> tuple though:
> >>
> >> if ([$_, $value] = array_first($array)) {
> >> // do something with $value
> >> }
> >>
> >> People who argue against the tuple because they don't like the design
> >> need to consider the bigger picture. The tuple way is less code,
> >> serves more use cases with fewer functions, and I even [implemented
> >> it][1]. If the array destructuring behavior seems unclear we can
> >> simply put an example in the manual pages for these functions --
> >> problem solved.
> >>
> >> This is not how RFC feedback should be handled. I hope more people
> >> vote no so we can reject this do it properly.
> >>
> > I do like this approach with two functions array_first & array_last
> > returning
> > a tuple. However, voting is underway and it looks like it will pass.
> >
> > I wonder what the RFC author (Enno W) thinks about that approach?
>
> This already has been discussed weeks ago, see
> <https://externals.io/message/102245#102317>;.
>
> --
> Christoph M. Becker

This was not discussed, it was discarded. Enormous difference.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, Jul 11, 2018 at 10:16 AM Levi Morrison <[email protected]> wrote:
>
> On Wed, Jul 11, 2018 at 9:27 AM Christoph M. Becker <[email protected]> wrote:
> >
> > On 11.07.2018 at 17:19, Björn Larsson wrote:
> >
> > > Den 2018-07-11 kl. 02:41, skrev Levi Morrison:
> > >
> > >> On Tue, Jul 10, 2018 at 12:59 PM Pedro Magalhães <[email protected]> wrote:
> > >>
> > >>> On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei <[email protected]> wrote:
> > >>>
> > >>>> I don't think we have an agreement on dealing with non-existing
> > >>>> value, and
> > >>>> the way this RFC proposed, just returning null without any
> > >>>> notice/warning,
> > >>>> is wrong IMO. I know we already do this in other array_* functions,
> > >>>> but we
> > >>>> cannot keep making mistakes just because we already made same mistake.
> > >>>>
> > >>> I voted no for the same reason. I'd even say that introducing a new
> > >>> array_
> > >>> function that still accepts non arrays just to return null with a
> > >>> warning
> > >>> doesn't make sense at this point.
> > >>>
> > >>> With that said, I'd gladly vote yes if there would be a way to
> > >>> distinguish
> > >>> array_value_first([]) from array_value_first([0 => null]).
> > >>>
> > >>> Regards,
> > >>> Pedro
> > >> To safely use it a call to empty or count or something needs to happen:
> > >>
> > >> if (!empty($array)) {
> > >> $value = array_value_first($array);
> > >> // do something with $value
> > >> }
> > >>
> > >> This is okay, but not great. Compare that to the design that returns a
> > >> tuple though:
> > >>
> > >> if ([$_, $value] = array_first($array)) {
> > >> // do something with $value
> > >> }
> > >>
> > >> People who argue against the tuple because they don't like the design
> > >> need to consider the bigger picture. The tuple way is less code,
> > >> serves more use cases with fewer functions, and I even [implemented
> > >> it][1]. If the array destructuring behavior seems unclear we can
> > >> simply put an example in the manual pages for these functions --
> > >> problem solved.
> > >>
> > >> This is not how RFC feedback should be handled. I hope more people
> > >> vote no so we can reject this do it properly.
> > >>
> > > I do like this approach with two functions array_first & array_last
> > > returning
> > > a tuple. However, voting is underway and it looks like it will pass.
> > >
> > > I wonder what the RFC author (Enno W) thinks about that approach?
> >
> > This already has been discussed weeks ago, see
> > <https://externals.io/message/102245#102317>;.
> >
> > --
> > Christoph M. Becker
>
> This was not discussed, it was discarded. Enormous difference.

As an example, it was claimed:

> If I use a function I expect it to give me a return value which I can
> use without any further post processing $wantedValue =
> fancyFunction($someInput);

But this isn't true even for the array_value_* functions. There must
be pre or post processing because of error conditions. This was
pointed out by myself and others, but it was still ignored.

This is what I mean by discarded, not discussed.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Tue, Jul 10, 2018 at 8:42 PM Levi Morrison <[email protected]> wrote:

> This is not how RFC feedback should be handled. I hope more people
> vote no so we can reject this do it properly.
>

I agree with the spirit of this RFC but I also agree with Levi. It feels
like this particular implementation is being rushed through without
properly addressing some of the outstanding issues and alternate
implementation ideas that have been raised. The only revisions to the RFC
were the inclusion of the two value-related functions. IMHO, any RFC going
to vote despite known "opposition" or requested changes should at least
contain a summary of those points and counter-points, but if feels like
those are being ignored here.

So while I do understand the value of such a feature, I'd much rather delay
its implementation than to rush it along with potential issues and no
strong consensus.

Respectfully,

Colin O'Dell
colinodell@gmail.com
https://www.colinodell.com
Hey,

any reason for not having both, resulting in a total of 6 functions?

Regards, Niklas

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 11.07.2018 um 18:20 schrieb Levi Morrison:

> As an example, it was claimed:
>
>> If I use a function I expect it to give me a return value which I can
>> use without any further post processing $wantedValue =
>> fancyFunction($someInput);
> But this isn't true even for the array_value_* functions. There must
> be pre or post processing because of error conditions. This was
> pointed out by myself and others, but it was still ignored.
>
> This is what I mean by discarded, not discussed.

In my eyes being aware of what I put into a function and thus catching
non array inputs and empty inputs before differs a lot from post
processing return values as it increases the comprehensibility of the
code. I also can think of cases where the input format is known and no
further checks are required.

Additionally the tuple return pattern is not common among the PHP core
functions and I don't know many occurences of this pattern in userland
PHP code neither at the companies I've worked at nor at open source
software/frameworks (correct me if I'm wrong) except the by far outdated
old foreach construct with reset() and each(), thus I assume it's not a
that common pattern for PHP developers to use it in core functions.

As I pointed out during the discussion we should also watch at existing
functions with the same problem, differ between a valid return value and
an error.
Not all of them can be changed to use different return mechanisms like
the tuple return pattern (eg. array_pop).

Maybe we can instead think about changing Z_PARAM_ARRAY_EX in a later
stage to not return null in error cases but instead throw an
InvalidArgumentException or something like that (at least for function
calls with an empty array for functions which require a filled array,
for invalid types maybe a fatal TypeError like it's thrown when a type
hinted argument in a userland function is violated is the correct
choice). Would be a pretty large BC breaking change but it would be
consistent among the array functions.

In my opinion neither rejecting the RFC nor changing it to return tuples
solves the underlying problem.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, Jul 11, 2018 at 11:42 AM Woortmann, Enno <[email protected]> wrote:
>
> Am 11.07.2018 um 18:20 schrieb Levi Morrison:
>
> > As an example, it was claimed:
> >
> >> If I use a function I expect it to give me a return value which I can
> >> use without any further post processing $wantedValue =
> >> fancyFunction($someInput);
> > But this isn't true even for the array_value_* functions. There must
> > be pre or post processing because of error conditions. This was
> > pointed out by myself and others, but it was still ignored.
> >
> > This is what I mean by discarded, not discussed.
>
> In my eyes being aware of what I put into a function and thus catching
> non array inputs and empty inputs before differs a lot from post
> processing return values as it increases the comprehensibility of the
> code. I also can think of cases where the input format is known and no
> further checks are required.
>
> Additionally the tuple return pattern is not common among the PHP core
> functions and I don't know many occurences of this pattern in userland
> PHP code neither at the companies I've worked at nor at open source
> software/frameworks (correct me if I'm wrong) except the by far outdated
> old foreach construct with reset() and each(), thus I assume it's not a
> that common pattern for PHP developers to use it in core functions.
>
> As I pointed out during the discussion we should also watch at existing
> functions with the same problem, differ between a valid return value and
> an error.
> Not all of them can be changed to use different return mechanisms like
> the tuple return pattern (eg. array_pop).
>
> Maybe we can instead think about changing Z_PARAM_ARRAY_EX in a later
> stage to not return null in error cases but instead throw an
> InvalidArgumentException or something like that (at least for function
> calls with an empty array for functions which require a filled array,
> for invalid types maybe a fatal TypeError like it's thrown when a type
> hinted argument in a userland function is violated is the correct
> choice). Would be a pretty large BC breaking change but it would be
> consistent among the array 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. I have been working to solve this
by making a bidirectional array iterator that can start at either end
of the array and can traverse back and forth. This work will not ready
for 7.3, not even with the extension to the feature freeze because
there is some design that needs to happen; the work I have so far is
here:

https://github.com/php/php-src/compare/master...morrisonlevi:BidirectionalArrayIterator

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 11.07.2018 um 20:18 schrieb Levi Morrison:

>> 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.

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.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 11.07.2018 at 18:16, Levi Morrison wrote:

> On Wed, Jul 11, 2018 at 9:27 AM Christoph M. Becker <[email protected]> wrote:
>>
>> On 11.07.2018 at 17:19, Björn Larsson wrote:
>>
>>> I do like this approach with two functions array_first & array_last
>>> returning
>>> a tuple. However, voting is underway and it looks like it will pass.
>>>
>>> I wonder what the RFC author (Enno W) thinks about that approach?
>>
>> This already has been discussed weeks ago, see
>> <https://externals.io/message/102245#102317>;.
>
> This was not discussed, it was discarded. Enormous difference.

Well, there was some discussion. Particularly noteworthy, was Rowan's
post[1] which pointed out that the behavior of list is *undocumented*,
and Larry's post[2] which strongly advises against “multi-returns”.

And finally, as I understand it, the actual proposal that is put to vote
is what the RFC *author* wants to propose. There is no strict necessity
to deal with any suggestion for improvement. After all, it's up to the
voters whether a particular RFC will be accepted or rejected. If
anybody dislikes a certain RFC, they are free to point out their
concerns, and to vote against the RFC. Period.

[1] <https://externals.io/message/102245#102326>;
[2] <https://externals.io/message/102245#102326>;

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,

CHU Zhaowei wrote:
> I voted no.
> I don't think we have an agreement on dealing with non-existing value, and the way this RFC proposed, just returning null without any notice/warning, is wrong IMO. I know we already do this in other array_* functions, but we cannot keep making mistakes just because we already made same mistake.
>
> Regards,
> CHU Zhaowei
>

Hmm. Returning null with no warning makes perfect sense for keys, since
null is not a valid key so there's no ambiguity, but for values it seems
problematic. On that ground I've decided to change my vote to No for the
value functions, but keep the vote for Yes for the key functions.
Someone who wants such behaviour could always do
($array[array_key_last($array)] ?? null), I guess.

--
Andrea Faulds
https://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Le jeudi 12 juillet 2018, 01:04:36 CEST Andrea Faulds a écrit :
> Hmm. Returning null with no warning makes perfect sense for keys, since
> null is not a valid key so there's no ambiguity, but for values it seems
> problematic. On that ground I've decided to change my vote to No for the
> value functions, but keep the vote for Yes for the key functions.
> Someone who wants such behaviour could always do
> ($array[array_key_last($array)] ?? null), I guess.

You cannot do that easily if the array is returned by a function.
function()[array_key_last(function())] would call the function twice.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 12.07.2018 at 09:06, Côme Chilliet wrote:

> Le jeudi 12 juillet 2018, 01:04:36 CEST Andrea Faulds a écrit :
>
>> Hmm. Returning null with no warning makes perfect sense for keys, since
>> null is not a valid key so there's no ambiguity, but for values it seems
>> problematic. On that ground I've decided to change my vote to No for the
>> value functions, but keep the vote for Yes for the key functions.
>> Someone who wants such behaviour could always do
>> ($array[array_key_last($array)] ?? null), I guess.

Ditto!

> You cannot do that easily if the array is returned by a function.
> function()[array_key_last(function())] would call the function twice.

You can easily store the function's return value in a variable, though.

--
Christoph M. Becker



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, Jul 9, 2018 at 5:17 AM Woortmann, Enno <[email protected]> wrote:
>
> Hi,
>
> as the discussion got no new contributions I'd like to start the voting
> for the RFC fo add new functions for the handling of outer array elements.
>
> https://wiki.php.net/rfc/array_key_first_last
>
> To have a better separation I split up the vote for the functions. The
> first vote covers the functions to handle keys: array_key_first() and
> array_key_last(). The second vote covers the corresponding functions to
> handle the values: array_value_first() and array_value_last().
>
> As this RFC adds functions but doesn't change the language syntax a 50%
> + 1 majority is required for both votes. The votes are open until
> 2018-07-16.
>
> The discussion for this RFC is located at
>
> https://externals.io/message/102245
>
> Regards,
>
> Enno
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

This entire time I felt like this should be possible in pure PHP.
Surely, somewhere, we have this capability already? I searched quite a
few functions but didn't find anything.

However, the feeling was right. Just moments ago Paul Crovella from
Stack Overflow mentioned to me that `array_slice` uses the terminology
`offset` to refer to the order of the entry rather than its key, so I
went looking. As far as I can tell from the [array_slice
implementation][1] it will not trigger copies and will be efficient if
using -1 to retrieve the last index. We can provide the parameter
`preserve_keys` an argument of true to get both the key and the value.
These functions *are* efficiently implementable in user-land!

Below is a proof-of-concept for the `array_offset` function [mentioned
by Nicolas Grekas][2] (which by the way, neither the RFC author nor
anyone else responded to this suggestion) that is simply a convenience
wrapper over `array_slice`:

function array_offset(array $input, int $offset): ?array {
$slice = array_slice($input, $offset, 1, true);
return count($slice) ? $slice : null;
}

$assoc = ['one' => 1, 'two' => 2, 'three' => 3];
$packd = range(1, 4);

var_dump(array_offset($assoc, -1));
var_dump(array_offset($packd, -1));

var_dump(array_offset($assoc, 0));
var_dump(array_offset($packd, 0));

Of course, the `array_slice` function can be used to build all of the
functions described in the RFC, as well.

My new opinion is that no new functions are required and that
improving the `array_slice` documentation is all that is necessary. It
currently does not show any examples of it working on associated
arrays, which is probably why none of us (many of us experts) realized
this through this discussion. This is especially true as "offset" in
some other situations really means "key", as in
`ArrayAccess::offsetGet`.

[1]: https://github.com/php/php-src/blob/b9963969fd088dca6852483fdb1c6b7e1080764d/ext/standard/array.c#L3477-L3577
[2]: https://externals.io/message/102245#102322

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, Jul 13, 2018 at 4:48 PM Levi Morrison <[email protected]> wrote:
>
> On Mon, Jul 9, 2018 at 5:17 AM Woortmann, Enno <[email protected]> wrote:
> >
> > Hi,
> >
> > as the discussion got no new contributions I'd like to start the voting
> > for the RFC fo add new functions for the handling of outer array elements.
> >
> > https://wiki.php.net/rfc/array_key_first_last
> >
> > To have a better separation I split up the vote for the functions. The
> > first vote covers the functions to handle keys: array_key_first() and
> > array_key_last(). The second vote covers the corresponding functions to
> > handle the values: array_value_first() and array_value_last().
> >
> > As this RFC adds functions but doesn't change the language syntax a 50%
> > + 1 majority is required for both votes. The votes are open until
> > 2018-07-16.
> >
> > The discussion for this RFC is located at
> >
> > https://externals.io/message/102245
> >
> > Regards,
> >
> > Enno
> >
> >
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
> This entire time I felt like this should be possible in pure PHP.
> Surely, somewhere, we have this capability already? I searched quite a
> few functions but didn't find anything.
>
> However, the feeling was right. Just moments ago Paul Crovella from
> Stack Overflow mentioned to me that `array_slice` uses the terminology
> `offset` to refer to the order of the entry rather than its key, so I
> went looking. As far as I can tell from the [array_slice
> implementation][1] it will not trigger copies and will be efficient if
> using -1 to retrieve the last index. We can provide the parameter
> `preserve_keys` an argument of true to get both the key and the value.
> These functions *are* efficiently implementable in user-land!
>
> Below is a proof-of-concept for the `array_offset` function [mentioned
> by Nicolas Grekas][2] (which by the way, neither the RFC author nor
> anyone else responded to this suggestion) that is simply a convenience
> wrapper over `array_slice`:
>
> function array_offset(array $input, int $offset): ?array {
> $slice = array_slice($input, $offset, 1, true);
> return count($slice) ? $slice : null;
> }
>
> $assoc = ['one' => 1, 'two' => 2, 'three' => 3];
> $packd = range(1, 4);
>
> var_dump(array_offset($assoc, -1));
> var_dump(array_offset($packd, -1));
>
> var_dump(array_offset($assoc, 0));
> var_dump(array_offset($packd, 0));
>
> Of course, the `array_slice` function can be used to build all of the
> functions described in the RFC, as well.
>
> My new opinion is that no new functions are required and that
> improving the `array_slice` documentation is all that is necessary. It
> currently does not show any examples of it working on associated
> arrays, which is probably why none of us (many of us experts) realized
> this through this discussion. This is especially true as "offset" in
> some other situations really means "key", as in
> `ArrayAccess::offsetGet`.
>
> [1]: https://github.com/php/php-src/blob/b9963969fd088dca6852483fdb1c6b7e1080764d/ext/standard/array.c#L3477-L3577
> [2]: https://externals.io/message/102245#102322

Small correction: Nicolas used the name `array_index`, not `array_offset`.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, Jul 13, 2018 at 4:50 PM Levi Morrison <[email protected]> wrote:
>
> On Fri, Jul 13, 2018 at 4:48 PM Levi Morrison <[email protected]> wrote:
> >
> > On Mon, Jul 9, 2018 at 5:17 AM Woortmann, Enno <[email protected]> wrote:
> > >
> > > Hi,
> > >
> > > as the discussion got no new contributions I'd like to start the voting
> > > for the RFC fo add new functions for the handling of outer array elements.
> > >
> > > https://wiki.php.net/rfc/array_key_first_last
> > >
> > > To have a better separation I split up the vote for the functions. The
> > > first vote covers the functions to handle keys: array_key_first() and
> > > array_key_last(). The second vote covers the corresponding functions to
> > > handle the values: array_value_first() and array_value_last().
> > >
> > > As this RFC adds functions but doesn't change the language syntax a 50%
> > > + 1 majority is required for both votes. The votes are open until
> > > 2018-07-16.
> > >
> > > The discussion for this RFC is located at
> > >
> > > https://externals.io/message/102245
> > >
> > > Regards,
> > >
> > > Enno
> > >
> > >
> > >
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> > This entire time I felt like this should be possible in pure PHP.
> > Surely, somewhere, we have this capability already? I searched quite a
> > few functions but didn't find anything.
> >
> > However, the feeling was right. Just moments ago Paul Crovella from
> > Stack Overflow mentioned to me that `array_slice` uses the terminology
> > `offset` to refer to the order of the entry rather than its key, so I
> > went looking. As far as I can tell from the [array_slice
> > implementation][1] it will not trigger copies and will be efficient if
> > using -1 to retrieve the last index. We can provide the parameter
> > `preserve_keys` an argument of true to get both the key and the value.
> > These functions *are* efficiently implementable in user-land!
> >
> > Below is a proof-of-concept for the `array_offset` function [mentioned
> > by Nicolas Grekas][2] (which by the way, neither the RFC author nor
> > anyone else responded to this suggestion) that is simply a convenience
> > wrapper over `array_slice`:
> >
> > function array_offset(array $input, int $offset): ?array {
> > $slice = array_slice($input, $offset, 1, true);
> > return count($slice) ? $slice : null;
> > }
> >
> > $assoc = ['one' => 1, 'two' => 2, 'three' => 3];
> > $packd = range(1, 4);
> >
> > var_dump(array_offset($assoc, -1));
> > var_dump(array_offset($packd, -1));
> >
> > var_dump(array_offset($assoc, 0));
> > var_dump(array_offset($packd, 0));
> >
> > Of course, the `array_slice` function can be used to build all of the
> > functions described in the RFC, as well.
> >
> > My new opinion is that no new functions are required and that
> > improving the `array_slice` documentation is all that is necessary. It
> > currently does not show any examples of it working on associated
> > arrays, which is probably why none of us (many of us experts) realized
> > this through this discussion. This is especially true as "offset" in
> > some other situations really means "key", as in
> > `ArrayAccess::offsetGet`.
> >
> > [1]: https://github.com/php/php-src/blob/b9963969fd088dca6852483fdb1c6b7e1080764d/ext/standard/array.c#L3477-L3577
> > [2]: https://externals.io/message/102245#102322
>
> Small correction: Nicolas used the name `array_index`, not `array_offset`.

Unfortunately I was too hasty: `array_slice` will iterate over the
entire input range:

https://github.com/php/php-src/blob/b9963969fd088dca6852483fdb1c6b7e1080764d/ext/standard/array.c#L3538-L3552

We could add an case for when `array_slice` uses `-1`. I wonder how
common this already is. Does anyone have a tool that easily can search
open source code for usages of functions? I am interested in this
regardless of the outcome of this RFC. The documentation for
`array_slice` should also be updated independently of this RFC as
well.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
A function like array_offset would be convenient as there is no way to
access the value of an array entry by its index currently. The workaround
is using array_slice, with all the downsides already pointed out.

2018-07-13 20:04 GMT-03:00 Levi Morrison <[email protected]>:

> On Fri, Jul 13, 2018 at 4:50 PM Levi Morrison <[email protected]> wrote:
> >
> > On Fri, Jul 13, 2018 at 4:48 PM Levi Morrison <[email protected]> wrote:
> > >
> > > On Mon, Jul 9, 2018 at 5:17 AM Woortmann, Enno <[email protected]>
> wrote:
> > > >
> > > > Hi,
> > > >
> > > > as the discussion got no new contributions I'd like to start the
> voting
> > > > for the RFC fo add new functions for the handling of outer array
> elements.
> > > >
> > > > https://wiki.php.net/rfc/array_key_first_last
> > > >
> > > > To have a better separation I split up the vote for the functions.
> The
> > > > first vote covers the functions to handle keys: array_key_first() and
> > > > array_key_last(). The second vote covers the corresponding functions
> to
> > > > handle the values: array_value_first() and array_value_last().
> > > >
> > > > As this RFC adds functions but doesn't change the language syntax a
> 50%
> > > > + 1 majority is required for both votes. The votes are open until
> > > > 2018-07-16.
> > > >
> > > > The discussion for this RFC is located at
> > > >
> > > > https://externals.io/message/102245
> > > >
> > > > Regards,
> > > >
> > > > Enno
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > PHP Internals - PHP Runtime Development Mailing List
> > > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > > This entire time I felt like this should be possible in pure PHP.
> > > Surely, somewhere, we have this capability already? I searched quite a
> > > few functions but didn't find anything.
> > >
> > > However, the feeling was right. Just moments ago Paul Crovella from
> > > Stack Overflow mentioned to me that `array_slice` uses the terminology
> > > `offset` to refer to the order of the entry rather than its key, so I
> > > went looking. As far as I can tell from the [array_slice
> > > implementation][1] it will not trigger copies and will be efficient if
> > > using -1 to retrieve the last index. We can provide the parameter
> > > `preserve_keys` an argument of true to get both the key and the value.
> > > These functions *are* efficiently implementable in user-land!
> > >
> > > Below is a proof-of-concept for the `array_offset` function [mentioned
> > > by Nicolas Grekas][2] (which by the way, neither the RFC author nor
> > > anyone else responded to this suggestion) that is simply a convenience
> > > wrapper over `array_slice`:
> > >
> > > function array_offset(array $input, int $offset): ?array {
> > > $slice = array_slice($input, $offset, 1, true);
> > > return count($slice) ? $slice : null;
> > > }
> > >
> > > $assoc = ['one' => 1, 'two' => 2, 'three' => 3];
> > > $packd = range(1, 4);
> > >
> > > var_dump(array_offset($assoc, -1));
> > > var_dump(array_offset($packd, -1));
> > >
> > > var_dump(array_offset($assoc, 0));
> > > var_dump(array_offset($packd, 0));
> > >
> > > Of course, the `array_slice` function can be used to build all of the
> > > functions described in the RFC, as well.
> > >
> > > My new opinion is that no new functions are required and that
> > > improving the `array_slice` documentation is all that is necessary. It
> > > currently does not show any examples of it working on associated
> > > arrays, which is probably why none of us (many of us experts) realized
> > > this through this discussion. This is especially true as "offset" in
> > > some other situations really means "key", as in
> > > `ArrayAccess::offsetGet`.
> > >
> > > [1]: https://github.com/php/php-src/blob/
> b9963969fd088dca6852483fdb1c6b7e1080764d/ext/standard/array.c#L3477-L3577
> > > [2]: https://externals.io/message/102245#102322
> >
> > Small correction: Nicolas used the name `array_index`, not
> `array_offset`.
>
> Unfortunately I was too hasty: `array_slice` will iterate over the
> entire input range:
>
> https://github.com/php/php-src/blob/b9963969fd088dca6852483fdb1c6b
> 7e1080764d/ext/standard/array.c#L3538-L3552
>
> We could add an case for when `array_slice` uses `-1`. I wonder how
> common this already is. Does anyone have a tool that easily can search
> open source code for usages of functions? I am interested in this
> regardless of the outcome of this RFC. The documentation for
> `array_slice` should also be updated independently of this RFC as
> well.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
On Thu, Jul 12, 2018 at 8:05 AM Andrea Faulds <[email protected]> wrote:

> Hi,
>
> CHU Zhaowei wrote:
> > I voted no.
> > I don't think we have an agreement on dealing with non-existing value,
> and the way this RFC proposed, just returning null without any
> notice/warning, is wrong IMO. I know we already do this in other array_*
> functions, but we cannot keep making mistakes just because we already made
> same mistake.
> >
> > Regards,
> > CHU Zhaowei
> >
>

Since PHP supports null coalesce, it makes sense applying null coalesce by
default.
Many users do it for inputs. e.g $var = $_GET['var'] ?? null;


>
> Hmm. Returning null with no warning makes perfect sense for keys, since
> null is not a valid key so there's no ambiguity, but for values it seems
> problematic. On that ground I've decided to change my vote to No for the
> value functions, but keep the vote for Yes for the key functions.
> Someone who wants such behaviour could always do
> ($array[array_key_last($array)] ?? null), I guess.
>

When array_value_last($array) is needed, users would want null coalesce
almost always.
When user don't want it, they can

if (array_key_last($array) === NULL) { // Or if (!count($array)) {
die("hey, no value defined");
}
$var = array_value_last($array);

This usage would be rare and use of ($array[array_key_last($array)] ??
null) for null coalesce is pain.
It lacks API consistency as well.
Therefore, I voted "yes" for both.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net
Sorry, only registered users may post in this forum.

Click here to login