Re: Supporting ArrayObject in array_* functions

Until now I tried to find the easiest possible solution. Currently we have two paths to chose: 1- A class that implements ArrayAccess must be useable everywhere an "array" is useable; 2- ArrayAccess needs to be expanded with methods for all the array functions and ArrayObject needs to implement them; I was choosing the approach 1 since it was easier and with less impact on source. Since you want something better designed, we'll have to go on 2nd option. Please notice I do not want to override our current implementation of arrays in PHP, but it will bring 2 main advantages: A- It does not require hacking PHP array functions B- It gives you an OO interface The idea then was to keep it as an alternative, not a replacement. What's the scope them, you may ask me. Here it is: http://www.php.net/manual/en/book.array.php If this implementation covers these functions, I'll be nice. How would it be achieved? $coll->sort(); instead of sort($coll); $coll2 = $coll->reverse(); instead of $coll2 = array_reverse($coll); Is this better now? Cheers, 2009/7/30 Johannes Schlüter <johannes@schlueters.de>: > On Thu, 2009-07-30 at 11:42 -0300, Guilherme Blanco wrote: >> I'm trying to avoid a "globally solution" on first instance to avoid a >> great impact on language. >> If you wanna ask me what's the global solution, I'll suggest a >> Collection like implementation for all array functions. > > Define "all array functions" - What you're ending up with is that one > has to always look up whether a given function takes an Object of some > kind or not. > > I'd rather have a "yes, unless there's something good reason not to" > >> This would lead to a simpler implementation. So, here are the answers >> of your questions: > > As said I didn't mean them as actual questions, but pointers to possible > problems in regards to a clean design. > >> > - is that specific to ArrayObject or do we "need" interfaces like >> > "Sortable" or "Shuffable" >> >> All Interfaces that can be treated as normal arrays (implements >> ArrayObject) should be supported. > > ArrayObject is no Interface but a concrete class that means everybody > extending from there creates a is-a relationship which might be quite > limiting. > >> Why not ArrayAccess on first stage? I do not consider it right now >> because it'll require the method getArrayCopy() to be moved from >> ArrayObject to ArrayAccess. >> >> > - What should stuff like array_merge(ArrayObject, array) do >> >> It should return an array, just like the current function prototype defines > > That was a simple case, agreed, but thee might be cases where it's > probably not that clear what type should be used so again this should be > seen globally t come up with a as consistent solution as possible. > >> > - Should we do this globally? (should ldap_set_option() allow an ArrayObject as 3rd >> > param?) >> >> This can be obviously be considered... but at the first step, let's be >> strict to the plan an only support array operations. > > Why isn't that an "array operation"? Where's the strict line? Any > function prefixed with array_? - Then sort() would be ignored. Anything > in ext/standard using arrays? Then don't forget str_replace and other > functions ... and that's not clear for users. So where's the strict > line? > >> Basically what would be the approach I'm looking for? >> For all array_* functions, inspect if given parameter is an array or >> an instance of ArrayObject. >> If instance of ArrayObject, call ArrayObject::getArrayCopy() and >> proceed normally with execution of each array_* function. It can't be >> that hard! =) > > By using getArrayCopy you are introducing quite possibly a huge > performance penalty for using ArrayObject ... creating a copy of the > HashTable just for throwing it away a moment later. > > Yes, such an implementation would be trivial but I don't think it's what > we'd want. > > johannes > > > -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9215-8480 MSN: guilhermeblanco@hotmail.com URL: http://blog.bisna.com São Paulo - SP/Brazil