Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45155
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.221.203 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=PiuXMLRJiSyAvaiXlWVgybGVPRLhfZ6REAg8qGApNNI5P31Tnjr98ZLS+Y/sC4l9+a
         bWVdWnkbY94A1gwjCDyIIbRZ0fdTo4c1RgGpcre/gsUBk+QW0p/5q7hMj1rVw8QJHfPz
         EHubUlzkXZa9HpRJfyqkv2GP1HiZoHwvynYzU=
MIME-Version: 1.0
In-Reply-To: <4A71E4DD.2090005@zend.com>
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>
	 <bcb7aa500907301015l3331ab91rd123a85fdfe80d5@mail.gmail.com>
	 <4A71E4DD.2090005@zend.com>
Date: Thu, 30 Jul 2009 16:06:06 -0300
Message-ID: <bcb7aa500907301206p3f52b035r8f16eb89df82fdf2@mail.gmail.com>
To: Stanislav Malyshev <stas@zend.com>
Cc: =?UTF-8?Q?Johannes_Schl=C3=BCter?= <johannes@schlueters.de>, 
	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)

Hi Stan,

I don't really know which implementation is preferrable.
I just dropped the idea here first. Once decided, I can write a detailed RF=
C.

With some initial help, I can work on the patch to support it. I'm not
expert in internals, so some help will be surely needed.

I'm totally opened to suggestions. If chosen the approach 2, I'd like
to consider naming that Roman said: SplCollection and SplArray.
We can also merge with your idea to split into small subsets.... but
surely the array OO native implementation (Collection, SplArray, etc)
must implement all of them.

So... what do I need to do to move this idea forward? Open a poll
about which approach should be considered for RFC?


Cheers,

On Thu, Jul 30, 2009 at 3:22 PM, Stanislav Malyshev<stas@zend.com> wrote:
> Hi!
>
>> 1- A class that implements ArrayAccess must be useable everywhere an
>> "array" is useable;
>
> The problem is that many functions dealing with arrays do not make sense
> with generic object. For others, it may make sense in theory, but not be
> practical - e.g., suppose you have ArrayAccess object referring to a
> database field, how easy would be to make shuffle() work on it? How
> practical would it be?
>
>> 2- ArrayAccess needs to be expanded with methods for all the array
>> functions and ArrayObject needs to implement them;
>
> All 70+ of them? That'd be one fat interface.
>
>> How would it be achieved?
>> $coll->sort(); instead of sort($coll);
>> $coll2 =3D $coll->reverse(); instead of $coll2 =3D array_reverse($coll);
>
> Note that this also eats up a lot of useful names, and makes you implemen=
t
> functions that you would never use, such as picking a random element or
> finding difference between arrays.
>
> I think all array operations should be divided into following classes:
> 1. Basic ones, probably ArrayAccess/Iterator interface should be enough
> 2. Compound ones implemented on top of basic ones (i.e. array_sum is a
> combination of iteration and +, etc.)
> 3. Additional operations non-reducible to (1), like shift/unsift or exoti=
c
> ones like array_change_key_case().
>
> First two classes are easy to handle, the last one should be handled
> separately on per-case basis.
> --
> Stanislav Malyshev, Zend Software Architect
> stas@zend.com =C2=A0 http://www.zend.com/
> (408)253-8829 =C2=A0 MSN: stas@zend.com
>



--=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