Internal iteration API View as Markdown

Just picking some random example:

  * `array_map()` - This can be implemented using that infrastructure.
    (While some might think about returning an Traversable object if
    a Traversable object got put in, maybe a FilterIterator but
    let's ignore that)
  * `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 meant array_walk(). array_filter() shouldn't be an issue either.
That happens, when you shorten a list of examples ...

johannes

Johannes,

One thing to keep in mind when doing this is to think about consistency.

I think that's a huge point not to be taken lightly. For that reason, I
think that this API should not be used for any of the array_* functions.
Meaning that array_sum(), etc should all take arrays only.

Then, other non-array functions (such as str_replace, etc) can be modified
to use this new method.

Just my $0.02 anyway...

Anthony

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

On Thu, Jul 12, 2012 at 1:49 AM, Johannes Schlüter
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