Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80712
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.52 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CALKiJKpeuuJ2q1HLsCmb_Pq_FRX=G-s_H28Gdc+sq3isgA5q=g@mail.gmail.com>
References: <CAGa2bXYtYOwhDX7jbNtgWweHOAOXpw2UjwQzuZ5kr2xP6U6A0g@mail.gmail.com>
 <54B93AAD.6080308@gmail.com> <CAGa2bXYpUEQAv-xxDSo41za_SqdY-Q84U0hgrhVP85=BWDx=nQ@mail.gmail.com>
 <CALKiJKpeuuJ2q1HLsCmb_Pq_FRX=G-s_H28Gdc+sq3isgA5q=g@mail.gmail.com>
Date: Sun, 18 Jan 2015 10:01:04 +0900
Message-ID: <CAGa2bXbU7ss0CdAo0BTA+Dq9S=B7WfAzNzbVRR=NFrKyQqpCug@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1133d79adcb0ff050ce2bfdb
Subject: Re: [PHP-DEV] Fixing strange foreach behavior.
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a1133d79adcb0ff050ce2bfdb
Content-Type: text/plain; charset=UTF-8

Hi Rowan,

On Sat, Jan 17, 2015 at 8:43 PM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> My concern is, at what cost? Given how rarely used the internal pointer is,
> are we carrying around a chunk of extra memory with every array just on the
> off-chance that it will be used, or is there some magic that makes it
> zero-width until it's needed?
>
> Reusing it for foreach makes perfect sense if it increases performance for
> the majority of cases, and the only way to cover every edge-case like the
> one at the top of this thread would be to ban that optimisation outright.
> If there's some way of separating things such that the rarely used
> constructs take the performance hit, I'm all for it, though.
>

External position pointer needs a little more memory for sure. However,
external position pointer is used all over the place in standard and other
modules.

I agree that some benchmark should be taken before we proceed.

Alternatively, we could achieve consistency the other way round, by making
> foreach() reset the internal pointer even when it *doesn't* use it, and
> documenting that fact like we do for certain array functions. Code relying
> on the current behaviour when mixing them is probably buggy anyway, because
> it is not well-defined, so the BC concern should be low.
>

IIRC, there were discussions when foreach is added that point out internal
position
pointer usage. Before foreach, everyone was using current()/next()/reset().
I think
the reason foreach sets internal position pointer to the end was the code
used in
those days. It was not a technical/performance reasons, wasn't it? I don't
remember
well because it was more than 10 years ago. Anyone?

IIRC, foreach was introduced by Andi. I think foreach used external
position pointer and
didn't touch internal position pointer at all with his first proposal.
Please correct me if I'm
wrong.

As for nesting, I think PHP is doing the right thing for plain arrays and
> non-rewindable integrators, because I would expect a for each loop to start
> at the beginning, thus have an implicit reset/rewind. The rewindable
> behaviour is awkward, though - intuitively, the iteraror needs to be able
> to track multiple positions simultaneously, which isn't guaranteed by the
> interface design. Maybe an error should be issued if the integrator is
> already subject of a foreach loop?
>

Iterator is headache, I agree.
Iterator nesting may be detected by a flag easily, but it may be better to
generate
independent iterators for each "foreach".

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a1133d79adcb0ff050ce2bfdb--