Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80741
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXbU7ss0CdAo0BTA+Dq9S=B7WfAzNzbVRR=NFrKyQqpCug@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>
	<CAGa2bXbU7ss0CdAo0BTA+Dq9S=B7WfAzNzbVRR=NFrKyQqpCug@mail.gmail.com>
Date: Sun, 18 Jan 2015 15:05:41 +0000
Message-ID: <CALKiJKoXRN8b32qduhqNUny-Cs8Kf6SgvHhKQQRdZpmnwPC0rw@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1134694e0df39e050cee8a11
Subject: Re: [PHP-DEV] Fixing strange foreach behavior.
From: rowan.collins@gmail.com (Rowan Collins)

--001a1134694e0df39e050cee8a11
Content-Type: text/plain; charset=UTF-8

On 18 January 2015 at 01:01, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> 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.
>

I meant more that the internal pointer takes up memory which is unused by
99% of PHP applications, so we might as well get some benefit from it, but
it comes to the same thing.


> 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".
>
>
I don't think that's an either/or situation: in most cases, it would be up
to the user to create that independent iterator, because there's no general
algorithm for cloning one that the engine could use. (Think of an iterator
proxying a database cursor, for instance - it could be rewindable directly,
but cloning it would imply issuing a new query to create a new cursor with
separate state.) So the engine needs to issue an error telling the user
that they're reusing an object in an dangerous way. An extended interface
could be created later for those cases that can handle the situation,
although I doubt it would be that common a use case.


-- 
Rowan Collins
[IMSoP]

--001a1134694e0df39e050cee8a11--