Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45149
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.92.27 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=KT9dVRgGrmbCE025SYmH8mh6H6Pw+byTy3+q5h4SZ522bBtECpRMNJsuKY3eUrOx9I
         RShHuVjlw/kkkgmEcKXMNXwdGWh97sv5kU02Kmsf2RVowXBOBd6oyd6+M/wJlxJpWMXE
         ltUK89V3vsoHCKABZ9tXCai1lfEHnkyUS9c04=
MIME-Version: 1.0
In-Reply-To: <1248968847.4159.31.camel@goldfinger.johannes.nop>
References: <bcb7aa500907292008m67021b98s54938233a5783ddc@mail.gmail.com>
	 <1248962475.4159.14.camel@goldfinger.johannes.nop>
	 <cd5680a20907300710h2d6df431hfd1e03c83fc95a4e@mail.gmail.com>
	 <bcb7aa500907300742t44f95d6cr30cb13d1ac8fcaad@mail.gmail.com>
	 <1248968847.4159.31.camel@goldfinger.johannes.nop>
Date: Thu, 30 Jul 2009 14:15:53 -0300
Message-ID: <bcb7aa500907301015l3331ab91rd123a85fdfe80d5@mail.gmail.com>
To: =?UTF-8?Q?Johannes_Schl=C3=BCter?= <johannes@schlueters.de>
Cc: Alexey Zakhlestin <indeyets@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Supporting ArrayObject in array_* functions
From: guilhermeblanco@gmail.com (Guilherme Blanco)

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 =3D $coll->reverse(); instead of $coll2 =3D array_reverse($coll);


Is this better now?

Cheers,

2009/7/30 Johannes Schl=C3=BCter <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 "Sor=
table" 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 defi=
nes
>
> 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 Array=
Object 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! =3D)
>
> 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
>
>
>



--=20
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
URL: http://blog.bisna.com
S=C3=A3o Paulo - SP/Brazil