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.
http://en.wikipedia.org/wiki/Collection_%28computing%29 http://trac.doctrine-project.org/browser/trunk/lib/Doctrine/Common/Collections Since it's a too much impactable code, I prefer to go straight at the first glance to support basic operations, treating ArrayObjects as normal arrays. This would lead to a simpler implementation. So, here are the answers of your questions: > - 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. 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 > - 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. 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! =) Cheers, 2009/7/30 Alexey Zakhlestin <indey...@gmail.com>: > 2009/7/30 Johannes Schlüter <johan...@schlueters.de>: >> On Thu, 2009-07-30 at 00:08 -0300, Guilherme Blanco wrote: >>> What do you think about the possibility to support ArrayObject >>> instances in array_* functions? >>> If you all agreed on this, I can definately help to complete the >>> patch, but I need some initial guidance to finish at least the first >>> function. >> >> In general I'm for bringing Iterators/ArrayObject/.. on a line with >> arrays but please don't simply patch some functions but let's try to >> find a as consistent as possible global solution. >> >> Questions included there are of these kinds (just examples) >> - is that specific to ArrayObject or do we "need" interfaces like >> "Sortable" or "Shuffable" >> - What should stuff like aray_merge(ArrayObject, array) do >> - Should we do this globally? (should ldap_set_option() >> allow an ArrayObject as 3rd param?) >> >> Especially the latter shows that a proper solution might be not to patch >> individual functions but to introduce some form of abstraction from >> HashTables for "array operations" and then use that interface. >> >> Simply extending a few functions will end in a mess but looking around >> people seem to love these structures so improving them is good. > > agreed. > the proper solution would be to define several interfaces, make > functions accept objects of these interfaces and then add some > "hacks", which would pretend, that array() implements these. > > -- > Alexey Zakhlestin > http://www.milkfarmsoft.com/ > Sent from St Petersburg, Russian Federation > -- 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
