Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96640
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.68 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c_7g_YdxTfUX8t_OifVJTL=OcvjsC_smWc95M-CcRYaNw@mail.gmail.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>
Date: Sun, 30 Oct 2016 11:31:27 +0700
Message-ID: <CAEZPtU4T-nVBq6HqHgPMT7VWajGHnf-=gnUQNE2MP4ZC1KvDFw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Levi Morrison <levim@php.net>, David Lundgren <dlundgren@syberisle.net>, 
	internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Allow Iterator to be used with current, next, reset,
 key functions
From: pierre.php@gmail.com (Pierre Joye)

hi Nikita,

On Sun, Oct 30, 2016 at 3:06 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> On Fri, Oct 28, 2016 at 2:43 PM, Levi Morrison <levim@php.net> wrote:
>
>> On Wed, Oct 26, 2016 at 7:42 AM, David Lundgren <dlundgren@syberisle.net>
>> wrote:
>> > Greetings,
>> >
>> > As suggested by several reviewers of a PR[1] I recently submitted, I'd
>> > like to get feedback on letting custom Iterators be used in the current,
>> > next, reset, and key functions. If this is something to move forward
>> > with, I'll need some help with the RFC process.
>> >
>> > Recent experiences trying to use these functions with a custom Iterator,
>> > and a bug[2], led me to try and fix this. BC will occur when an object
>> > implementing Iterator is passed to one of the functions, as the
>> > interface methods will be called, instead of returning the objects
>> > properties. The old behavior should be maintained for classes that do
>> > not implement Iterator.
>> >
>> > [1] https://github.com/php/php-src/pull/2176
>> > [2] https://bugs.php.net/bug.php?id=49369
>> >
>> > Thanks,
>> > Dave
>> > --
>> > David Lundgren
>> > dlundgren@syberisle.net
>> > 808.639.0365
>> > GPG: 0x26F54D7F
>> >
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: http://www.php.net/unsub.php
>>
>> I can't seem to recall specifics anymore but I do believe some people
>> would greatly prefer to remove the internal array pointer for
>> iteration and deprecate these functions. Maybe someone else can
>> remember more? Nikita and Bob, maybe?
>>
>
> Yeah, I'm one of those people. In PHP 7 the most important user of the IAP,
> foreach, was switched to use a more robust mechanism. I believe that at
> this point, the concept of an internal array pointer has outlived its
> usefulness and we should be working toward removing any APIs that publicly
> expose it, including each and the next/current/key family of functions. I
> will propose to deprecate each() in particular for PHP 7.2, because it is
> both more problematic and more useless than the others, but I'd like to see
> the others go away in the long term as well. If people want fine-grained
> control over array iteration, they should use an external iterator (aka
> ArrayIterator), not an internal one.


How do iterators compare to a for/while/custom loops using
next/current/etc? I did not bench it lately but last time there was a
significant impact when using Iterators.

I also think it is a good thing to clean up the ways to work with
arrays or iterable but we have to be very careful how we do it. I am
not sure an actual deprecation is a good thing in 7.x without breaking
any kind of tests out there. Indeed it will not break code but it is
rather bad to break tests and it is a very annoying thing to do while
trying to be good at using the latest PHP version.

I am not sure if a documentation+UPGRADE guide and all possible
communications about such deprecations would be enough. Maybe only
until we reach the last version before 8.0 (which can use actual
deprecations warnings, given we have more than 7.2 before 8.0).

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org