Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61153
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.153 as permitted sender)
Message-ID: <4FFE5BC9.9050005@sugarcrm.com>
Date: Wed, 11 Jul 2012 22:08:25 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: =?UTF-8?B?Sm9oYW5uZXMgU2NobMO8dGVy?= <johannes@schlueters.de>
CC: Nikita Popov <nikita.ppv@gmail.com>, 
 PHP internals <internals@lists.php.net>
References: <CAF+90c-eG_+7ZpGzu-ownYnTDUvVJwHgCH=xOvnOa9sAYKNHjA@mail.gmail.com> <1342050547.1456.33.camel@guybrush>
In-Reply-To: <1342050547.1456.33.camel@guybrush>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Internal iteration API
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> 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.

We could create duplicates for functions that can accept Traversable and
give them neutrally sounding names. Though I don't see the reason why we
should ban something like array_map from accepting Traversable just
because some of the array_* functions don't - the question then would be
if there would be iterator_map() that accepts any Traversable why should
separate array_map exist at all?

Something like preg_grep should just accept any Traversable though.

>         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

Can we have the wrapper handle it? I.e. if the function calls
iterator_next(iterator), and it's a custom one which throws an exception
in next() then iterator_next() should take care of it and return that
there's no next element. Though I really don't see why such functions
should be allowed to throw exceptions - this seems overcomplicated to me
as then you can have exceptions thrown by most innocent operations like
str_replace, and it'd be very hard to handle such exceptions.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227