Hi Stan, I don't really know which implementation is preferrable. I just dropped the idea here first. Once decided, I can write a detailed RFC.
With some initial help, I can work on the patch to support it. I'm not expert in internals, so some help will be surely needed. I'm totally opened to suggestions. If chosen the approach 2, I'd like to consider naming that Roman said: SplCollection and SplArray. We can also merge with your idea to split into small subsets.... but surely the array OO native implementation (Collection, SplArray, etc) must implement all of them. So... what do I need to do to move this idea forward? Open a poll about which approach should be considered for RFC? Cheers, On Thu, Jul 30, 2009 at 3:22 PM, Stanislav Malyshev<s...@zend.com> wrote: > Hi! > >> 1- A class that implements ArrayAccess must be useable everywhere an >> "array" is useable; > > The problem is that many functions dealing with arrays do not make sense > with generic object. For others, it may make sense in theory, but not be > practical - e.g., suppose you have ArrayAccess object referring to a > database field, how easy would be to make shuffle() work on it? How > practical would it be? > >> 2- ArrayAccess needs to be expanded with methods for all the array >> functions and ArrayObject needs to implement them; > > All 70+ of them? That'd be one fat interface. > >> How would it be achieved? >> $coll->sort(); instead of sort($coll); >> $coll2 = $coll->reverse(); instead of $coll2 = array_reverse($coll); > > Note that this also eats up a lot of useful names, and makes you implement > functions that you would never use, such as picking a random element or > finding difference between arrays. > > I think all array operations should be divided into following classes: > 1. Basic ones, probably ArrayAccess/Iterator interface should be enough > 2. Compound ones implemented on top of basic ones (i.e. array_sum is a > combination of iteration and +, etc.) > 3. Additional operations non-reducible to (1), like shift/unsift or exotic > ones like array_change_key_case(). > > First two classes are easy to handle, the last one should be handled > separately on per-case basis. > -- > Stanislav Malyshev, Zend Software Architect > s...@zend.com http://www.zend.com/ > (408)253-8829 MSN: s...@zend.com > -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com URL: http://blog.bisna.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
