On Thu, Jul 12, 2012 at 1:49 AM, Johannes Schlüter <johan...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
