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
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
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 =
> >>
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
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
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
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 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:
> >>>
>
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
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
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
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
> 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
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
(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:
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
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
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
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
19 matches
Mail list logo
