Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96646
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.217.179 cause and error)
MIME-Version: 1.0
In-Reply-To: <01f2f3da-592b-fd23-709d-ad620422f56d@fleshgrinder.com>
References: <44244cfd-c8ad-e0a9-4e70-380a8a8c940c@syberisle.net>
 <CAFMT4Nr+d1k20aY0P9o1G9KU_C9wz2cg2UOPrbE3qbXDBhqe3w@mail.gmail.com>
 <CAF+90c_7g_YdxTfUX8t_OifVJTL=OcvjsC_smWc95M-CcRYaNw@mail.gmail.com>
 <CADqTB_jN6RQxEP5tAJY4T+kuv_rkTzRNvL9T1j-iVX5LG5H3Gg@mail.gmail.com>
 <CAF+90c_rE7DiJ8KEYzFO9GHqx56rin+CiByPe7hRF0fUm-zKBQ@mail.gmail.com> <01f2f3da-592b-fd23-709d-ad620422f56d@fleshgrinder.com>
Date: Sun, 30 Oct 2016 13:31:34 +0100
Message-ID: <CADqTB_jReEH9pGpfKaYnuYiucPcJ7Y+74VL-mNuJJ+THkUFRVA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Cc: Nikita Popov <nikita.ppv@gmail.com>, Levi Morrison <levim@php.net>, 
	David Lundgren <dlundgren@syberisle.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Allow Iterator to be used with current, next, reset,
 key functions
From: rasmus@mindplay.dk (Rasmus Schultz)

On second thought, I agree with that - changing reset() and end()
doesn't make sense, because people know them and expect them to work
in a certain way. Likely a lot of people would actually continue to
use them with intermediary variables the way they do today. Better to
introduce a new pair of functions, since this will make it clear when
consumer code depends on the new behavior - if we update the existing
functions, that means you have to read code knowing which version of
these very common (and very old) functions you were expecting to call.

One thing though, since we have to introduce new functions, I would
not suggest these be array_first() and array_last(), but rather simply
first() and last(), and make then work with anything iterable, not
just arrays.

> Retrieving the first and last would mean to iterate all the results.

Well, retrieving the last would - retrieving the first would mean
iterating only over the first result. For a lot of use-cases, and
unbuffered database results in particular, this is precisely what
you'd want.

> An additional interface should be required for traversables in order to work with first and last.

I think it would be great to have that as an option - for cases where
you can and want to optimize retrieval of the last item, but I don't
think it should be required? For example, in the case of an unbuffered
database query, there is likely no optimization that can be made for
last() in the first place, since the database client/server are likely
using a protocol that doesn't even allow you to skip to the last
result; in that case, requiring everyone to implement a new interface,
which does nothing, isn't meaningful.


On Sun, Oct 30, 2016 at 1:07 PM, Fleshgrinder <php@fleshgrinder.com> wrote:
> On 10/30/2016 12:45 PM, Nikita Popov wrote:
>> On Sun, Oct 30, 2016 at 12:24 PM, Rasmus Schultz <rasmus@mindplay.dk> wrote:
>>
>>> With regards to deprecating array-functions that operate on the
>>> internal pointer - I'd like to just remind you of the fact that some
>>> of these functions, reset() and end() in particular, are often used
>>> not because someone cares about moving the internal pointer, but as a
>>> means of getting the first/last items of an array.
>>>
>>> If the internal pointers are removed, I'd like to suggest we improve
>>> the reset() and end() functions rather than removing them - there is
>>> an annoyance with these two functions presently: because they operate
>>> on the internal pointer, the force you to introduce often meaningless
>>> intermediary variables.
>>>
>>> That is, for example:
>>>
>>>     $last = end(explode(",", $comma_separated_values));
>>>
>>> Doesn't work. One is forced to introduce a variable:
>>>
>>>     $parts = explode(",", $comma_separated_values);
>>>     $last = end($parts);
>>>
>>> If internal pointers are removed, maybe the reset() and end()
>>> functions could be made to actually work consistently? Whether applied
>>> to an expression or variable.
>>>
>>
>> Yeah, I've been thinking about this as well. reset() and end() do seem to
>> be the most commonly used IAP functions -- while nobody actually cares
>> about their effect on the IAP. The thing is, if we remove all other
>> functions that allow users to inspect the IAP, then we can simply change
>> reset() and end() to return the first/last element. As they would no longer
>> actually modify the array, they would no longer accept their argument by
>> reference, so end(explode(...)) would also become legal (and additionally,
>> they would no longer have to do a full copy of their argument, like they
>> currently sometimes need to do).
>>
>> Nikita
>>
>
> I think it makes much more sense to deprecate all of them and introduce
> new ones that work in the way we want them to for several reasons.
> `end()` and `reset()` would have to continue working as they do until
> the next major release since people who use them might rely on the way
> they work. This means in effect that nobody can make her PHP 7 code PHP
> 8 ready up front.
>
> Instead we could directly introduce `array_first()` and `array_last()`
> with the next feature release -- even if the others are not deprecated
> -- and everyone can update their code or at least use it in new code.
>
> Changing `end()` and `reset()` in PHP 7 is imho way to dangerous!
>
> Another often asked/proposed question is whether they should accept
> traversables. I think especially for these two functions it's not easy
> to simply accept any kind of traversable. Think of an unbuffered
> database result which is effectively a remote pointer. Retrieving the
> first and last would mean to iterate all the results.
>
> An additional interface should be required for traversables in order to
> work with first and last.
>
> --
> Richard "Fleshgrinder" Fussenegger