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

2018-07-11 Thread 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()

2018-07-11 Thread 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()

2018-07-11 Thread 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()

2018-07-11 Thread 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()

2018-07-11 Thread 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()

2018-07-11 Thread 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()

2018-07-11 Thread 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()

2018-07-11 Thread 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()

2018-07-11 Thread 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()

2018-07-11 Thread 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()

2018-07-11 Thread 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()

2018-07-11 Thread 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()

2018-07-11 Thread 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()

2018-07-11 Thread 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()

2018-07-10 Thread 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()

2018-07-10 Thread 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()

2018-07-10 Thread 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()

2018-07-10 Thread 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()

2018-07-10 Thread 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