Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49230
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.21 cause and error)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: internals@lists.php.net
References: <4C5C1D2E.6070805@easyflirt.com>
 <op.vg0tsbw2idpuyk@damnation.dulce.lo.geleia.net>
 <4C5FEA03.8010801@easyflirt.com>
Date: Mon, 09 Aug 2010 15:24:52 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Organization: =?utf-8?Q?N=C3=BAcleo_de_Eng=2E_Biom=C3=A9di?=
 =?utf-8?Q?ca_do_IST?=
Message-ID: <op.vg6czotmidpuyk@cataphract>
In-Reply-To: <4C5FEA03.8010801@easyflirt.com>
User-Agent: Opera Mail/10.60 (Win32)
Subject: Re: [PHP-DEV] Indexing an array
From: glopes@nebm.ist.utl.pt ("Gustavo Lopes")

On Mon, 09 Aug 2010 12:44:03 +0100, mathieu.suen  
<mathieu.suen@easyflirt.com> wrote:

> On 08/06/2010 04:42 PM, Gustavo Lopes wrote:
>> On Fri, 06 Aug 2010 15:33:18 +0100, mathieu.suen
>> <mathieu.suen@easyflirt.com> wrote:
>>
>>> For now you can only index an array using a scalar type or a string.
>>> Is there some rfc or work going on to enlarge the possibility so that  
>>> it
>>> is possible to have some other object like:
>>>
>>> - closure
>>> - object
>>> - etc.
>>
>> I think the problem with that is how you are going to generate the
>> hash of arbitrary objects in order to store them in the hash table.
>> It's not like all PHP objects have a hashCode() method.
>
> IMHO It should.
>
>>
>> So the only plausible option would be to attribute the same hash to
>> all and the test all for equality on an insertion with a new key or in
>> the worst case scenario for updates and reads.
>>
>
> Since php is not referentially transparent I would rather use identity
> unless object can redefine equality.
>

Well, even if one could overcome the hash problem by using suboptimal  
methods like calling __toString (or even use spl_object_hash(), though  
we'd be limited to identity) as if  they were hashCode() methods, one big  
problem remains: the hash tables only store a simple integer (for  
numerical indexing) or a char * string (for string indexing) to identify  
the key. It would have to be changed to be able to store an object, and  
now we'd break a lot of code that expects keys to be either strings or  
integers, not to mention the arrays API would be more complicated that it  
already is.

SplObjectStorage is a so-so alternative because it only allows identity in  
indexing, but you seem to be OK with that.

As to it not working with array functions, you're right, it sucks. In  
fact, only array_key_exists and array_walk(_recursive) work with object  
(if you can call it "work").

Perhaps one path here is to change the array functions so that if they  
receive an object they try to cast it into an array with the cast_object  
handler/convert_object_to_type and change the current default  
implementation for standard objects, which only handles conversions to  
string, to also handle conversions to arrays by traversing the object, if  
possible. Not the most efficient thing to do, since it requires copying  
everything, but it would be easier than changing the array functions in a  
more profound fashion. The "H" parse argument is useless because it tries  
to call get_properties (by the way, I don't understand why  
convert_to_array(_ex) and convert_to_explicit_type prefer get_properties  
to cast_object).

-- 
Gustavo Lopes