Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61160
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1342050547.1456.33.camel@guybrush>
References: <CAF+90c-eG_+7ZpGzu-ownYnTDUvVJwHgCH=xOvnOa9sAYKNHjA@mail.gmail.com>
	<1342050547.1456.33.camel@guybrush>
Date: Thu, 12 Jul 2012 10:46:24 +0200
Message-ID: <CAF+90c_rjOBxhyHR9ypE-66=+FBfqbSyqB7BvN5mHQaa0smQpw@mail.gmail.com>
To: =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Internal iteration API
From: nikita.ppv@gmail.com (Nikita Popov)

On Thu, Jul 12, 2012 at 1:49 AM, Johannes Schl=FCter
<johannes@schlueters.de> wrote:
> One thing to keep in mind when doing this is to think about consistency.
> Right there's quite a distinction. Things either take an array or a
> Traversable object. We should think about not creating a mess when some
> functions, especially ones called array_foo() allow Traversable while
> others won't. So we might need the same infrastructure in regards to
> ArrayAccess to help this a bit.

Yes, I agree that overloading the array_* functions would be a bit
strange (but not *that* strange either). My personally favorite
approach would be to create new functions like sum(), product() and
reduce(), which would be array_sum(), array_product() and
array_reduce() equivalents, but accepting anything iterable as input.
The old array_* functions would obviously stay (maybe as aliases,
maybe complete separate).

For the array_map and array_filter I would do the same (i.e. create
map() and filter()), which would return an array when passed an array,
but return a (lazy) iterator when passed an iterator.

>       * array_filter() - This is almost the same as array_map() but we
>         can't implement it using Traversable, as current() (for good
>         reasons) returns no reference.

I'm not sure how array_filter() and references relate (maybe you meant
array_walk?), but in any case: get_iterator style object iterator
*can* support references. The function has a by_ref flag. But
currently userland iterators can't make use of this. This limitation
can be easily removed though, as far as I know. It is just a leftover
from previously existing technical limitations regarding interfaces
and references.

> Another "fun fact" might be that Traversable doesn't require keys to be
> unique. This can have strange results for things like array_map().

Yeah, that's one of the reasons why I would prefer map() to return an
iterator if an iterator is passed in. Another reason is that iterators
can be infinite, which obviously doesn't play nice when returning an
array. (And even if they aren't infinite, they may be large).

>         Ah, and maybe completely unrelated to the things above but not
>         to forget: When implementing this the code becomes more complex
>         as exceptions thrown in key(), current(), rewind() have to be
>         caught. With "classic" zend_hash iteration those operations will
>         succeed if there was a next element pointer. Maybe that can be
>         handled in a generic infrastructure, so we have less errors
>         later.

Yeah, you're right about that. It wouldn't be nice if one had to check
for errors after every single call :/

Nikita