Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45146
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 83.243.58.133 cause and error)
To: Guilherme Blanco <guilhermeblanco@gmail.com>
Cc: Alexey Zakhlestin <indeyets@gmail.com>, PHP internals <internals@lists.php.net>
In-Reply-To: <bcb7aa500907300742t44f95d6cr30cb13d1ac8fcaad@mail.gmail.com>
References: <bcb7aa500907292008m67021b98s54938233a5783ddc@mail.gmail.com>
	 <1248962475.4159.14.camel@goldfinger.johannes.nop>
	 <cd5680a20907300710h2d6df431hfd1e03c83fc95a4e@mail.gmail.com>
	 <bcb7aa500907300742t44f95d6cr30cb13d1ac8fcaad@mail.gmail.com>
Content-Type: text/plain
Date: Thu, 30 Jul 2009 17:47:27 +0200
Message-ID: <1248968847.4159.31.camel@goldfinger.johannes.nop>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Supporting ArrayObject in array_* functions
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

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