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

[Christoph M. Becker]

On 17.07.2018 at 01:13, Enno Woortmann wrote:

> Am 09.07.2018 um 13:16 schrieb Woortmann, Enno:
> 
>> https://wiki.php.net/rfc/array_key_first_last
> 
> The vote for this RFC has been closed. The vote for the initially RFC
> containing the functions array_key_first() and array_key_last() was
> accepted, the vote for the extended RFC (adding also array_value_first()
> and array_value_last()) was declined.

When time permits, please update the RFC to state that it has been
implemented for PHP 7.3.0 via commit 50516a6[1], and link to the manual
pages[2] (which should be online tomorrow).

[1] 
[2] 


-- 
Christoph M. Becker

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

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

[Enno Woortmann]

Am 09.07.2018 um 13:16 schrieb 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


Hello together,

The vote for this RFC has been closed. The vote for the initially RFC 
containing the functions array_key_first() and array_key_last() was 
accepted, the vote for the extended RFC (adding also array_value_first() 
and array_value_last()) was declined.


I'll update the pull request located at 
https://github.com/php/php-src/pull/3256 tomorrow and remove the 
array_value functions as well as adopt the code review remarks of 
derickr so the PR can be merged for PHP 7.3.


Thanks for the participation,
Enno



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

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

[Côme Chilliet]

Le vendredi 13 juillet 2018, 16:48:29 CEST Levi Morrison a écrit :
> 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.

How would you do that, since array_slice still gives you an associative array 
as a result?
array_values(array_slice($array, -1, 1, true))[0] is way less readable than 
array_last_value($array), and the question «how efficient is that and how many 
array copies are made?» becomes complicated to answer for non-initiated.
While with a native function you expect it to be as efficient as possible to do 
what you ask it.
(And as you state in your other mail in the end this array_slice solution is 
not as efficient as you expected)

I would have been fine with array_key($array, $offset=0) and 
array_value($array, $offset=0) instead of the 4 functions from the RFC to be 
able to use any offset.

Côme

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

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

[Levi Morrison]

Not sure what timezone you are in; current votes are:

Add array_key_first() and array_key_last()?
  - Yes (19)
  - No (13)

Add array_value_first() and array_value_last()?
  - Yes (16)
  - No (17)

The first vote will pass with 59.375%. The second fails at ~48.48%.

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

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

[Yasuo Ohgaki]

On Thu, Jul 12, 2018 at 8:05 AM Andrea Faulds  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
yohg...@ohgaki.net

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

[Marcos Passos]

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 :

> On Fri, Jul 13, 2018 at 4:50 PM Levi Morrison  wrote:
> >
> > On Fri, Jul 13, 2018 at 4:48 PM Levi Morrison  wrote:
> > >
> > > On Mon, Jul 9, 2018 at 5:17 AM Woortmann, Enno 
> 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
>
>

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

[Levi Morrison]

On Fri, Jul 13, 2018 at 4:50 PM Levi Morrison  wrote:
>
> On Fri, Jul 13, 2018 at 4:48 PM Levi Morrison  wrote:
> >
> > On Mon, Jul 9, 2018 at 5:17 AM Woortmann, Enno  
> > 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

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

[Levi Morrison]

On Fri, Jul 13, 2018 at 4:48 PM Levi Morrison  wrote:
>
> On Mon, Jul 9, 2018 at 5:17 AM Woortmann, Enno  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

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

[Levi Morrison]

On Mon, Jul 9, 2018 at 5:17 AM Woortmann, Enno  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

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

[Christoph M. Becker]

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

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

[Côme Chilliet]

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

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

[Andrea Faulds]

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

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

[Christoph M. Becker]

On 11.07.2018 at 18:16, Levi Morrison wrote:

> On Wed, Jul 11, 2018 at 9:27 AM Christoph M. Becker  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
>> .
> 
> 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] 
[2] 

-- 
Christoph M. Becker

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

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

[Enno Woortmann]

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

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

[Levi Morrison]

On Wed, Jul 11, 2018 at 11:42 AM Woortmann, Enno  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

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

[Woortmann, Enno]

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

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

[Niklas Keller]

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

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

[Colin O'Dell]

On Tue, Jul 10, 2018 at 8:42 PM Levi Morrison  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
colinod...@gmail.com
https://www.colinodell.com

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

[Levi Morrison]

On Wed, Jul 11, 2018 at 10:16 AM Levi Morrison  wrote:
>
> On Wed, Jul 11, 2018 at 9:27 AM Christoph M. Becker  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  wrote:
> > >>
> > >>> On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei  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
> > .
> >
> > --
> > 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

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

[Levi Morrison]

On Wed, Jul 11, 2018 at 9:27 AM Christoph M. Becker  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  wrote:
> >>
> >>> On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei  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
> .
>
> --
> 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

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

[Björn Larsson]

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  wrote:


On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei  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
.


Aha, tnx.

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

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

[Côme Chilliet]

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

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

[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  wrote:
>>
>>> On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei  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
.

-- 
Christoph M. Becker

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

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

[Björn Larsson]

Den 2018-07-11 kl. 02:41, skrev Levi Morrison:

On Tue, Jul 10, 2018 at 12:59 PM Pedro Magalhães  wrote:

On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei  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

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

[Levi Morrison]

> 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

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

[Côme Chilliet]

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

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

[Levi Morrison]

(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

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

[Levi Morrison]

On Tue, Jul 10, 2018 at 6:41 PM Levi Morrison  wrote:
>
> On Tue, Jul 10, 2018 at 12:59 PM Pedro Magalhães  wrote:
> >
> > On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei  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

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

[Levi Morrison]

On Tue, Jul 10, 2018 at 12:59 PM Pedro Magalhães  wrote:
>
> On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei  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

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

[Pedro Magalhães]

On Mon, Jul 9, 2018 at 6:31 PM CHU Zhaowei  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

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

[Dan Ackroyd]

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

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

[CHU Zhaowei]

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

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

[Levi Morrison]

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

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

[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