Re: Supporting ArrayObject in array_* functions

From: Date: Thu, 30 Jul 2009 15:47:27 +0000
Subject: Re: Supporting ArrayObject in array_* functions
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-45146@lists.php.net to get a copy of this message
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

« previous php.internals (#45146) next »