Re: Supporting ArrayObject in array_* functions
| From: | Johannes Schlüter | 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