Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45144
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=hnEcJAUvqyg6iw7ovZ12Xr/1TcP0Y2U9cZlXsyAV6vjOz3G1tKg/gvcn2MHmf7OZXb
         nj4sRW7E2fPjxKUM9NKvrrehaYT8TYZYqWn0FNsBFjV5mDgOPqr2XVUEtQMbb5VQL/sV
         3WlR4QQzUShRxSUwXZ9wwI5qYdt61Yfdnnmb8=
MIME-Version: 1.0
In-Reply-To: <cd5680a20907300710h2d6df431hfd1e03c83fc95a4e@mail.gmail.com>
References: <bcb7aa500907292008m67021b98s54938233a5783ddc@mail.gmail.com>
	 <1248962475.4159.14.camel@goldfinger.johannes.nop>
	 <cd5680a20907300710h2d6df431hfd1e03c83fc95a4e@mail.gmail.com>
Date: Thu, 30 Jul 2009 11:42:44 -0300
Message-ID: <bcb7aa500907300742t44f95d6cr30cb13d1ac8fcaad@mail.gmail.com>
To: Alexey Zakhlestin <indeyets@gmail.com>
Cc: =?UTF-8?Q?Johannes_Schl=C3=BCter?= <johannes@schlueters.de>, 
	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)

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.

http://en.wikipedia.org/wiki/Collection_%28computing%29
http://trac.doctrine-project.org/browser/trunk/lib/Doctrine/Common/Collecti=
ons

Since it's a too much impactable code, I prefer to go straight at the
first glance to support basic operations, treating ArrayObjects as
normal arrays.
This would lead to a simpler implementation. So, here are the answers
of your questions:

> - is that specific to ArrayObject or do we "need" interfaces like "Sortab=
le" or "Shuffable"

All Interfaces that can be treated as normal arrays (implements
ArrayObject) should be supported.
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

> - Should we do this globally? (should ldap_set_option() allow an ArrayObj=
ect 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.


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)


Cheers,

2009/7/30 Alexey Zakhlestin <indeyets@gmail.com>:
> 2009/7/30 Johannes Schl=C3=BCter <johannes@schlueters.de>:
>> On Thu, 2009-07-30 at 00:08 -0300, Guilherme Blanco wrote:
>>> What do you think about the possibility to support ArrayObject
>>> instances in array_* functions?
>>> If you all agreed on this, I can definately help to complete the
>>> patch, but I need some initial guidance to finish at least the first
>>> function.
>>
>> In general I'm for bringing Iterators/ArrayObject/.. on a line with
>> arrays but please don't simply patch some functions but let's try to
>> find a as consistent as possible global solution.
>>
>> Questions included there are of these kinds (just examples)
>> - is that specific to ArrayObject or do we "need" interfaces like
>> =C2=A0"Sortable" or "Shuffable"
>> - What should stuff like aray_merge(ArrayObject, array) do
>> - Should we do this globally? (should ldap_set_option()
>> =C2=A0allow an ArrayObject as 3rd param?)
>>
>> Especially the latter shows that a proper solution might be not to patch
>> individual functions but to introduce some form of abstraction from
>> HashTables for "array operations" and then use that interface.
>>
>> Simply extending a few functions will end in a mess but looking around
>> people seem to love these structures so improving them is good.
>
> agreed.
> the proper solution would be to define several interfaces, make
> functions accept objects of these interfaces and then add some
> "hacks", which would pretend, that array() implements these.
>
> --
> Alexey Zakhlestin
> http://www.milkfarmsoft.com/
> Sent from St Petersburg, Russian Federation
>



--=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