Re: Internal iteration API
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
Thread (24 messages)