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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
