Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79721
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.171 as permitted sender)
Message-ID: <54902917.8010803@gmail.com>
Date: Tue, 16 Dec 2014 12:44:07 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <548FEE87.7020602@gmail.com>	<549009EE.7040808@fischer.name>	<D5013CDA-61F7-467F-B896-F627D8DBA156@ajf.me>	<5490190A.6050805@beccati.com> <CAJ26g5QsP8NVv4UWUGpxwRK301VhMTm6Di99soAdWqh=kXXcZQ@mail.gmail.com>
In-Reply-To: <CAJ26g5QsP8NVv4UWUGpxwRK301VhMTm6Di99soAdWqh=kXXcZQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC][VOTE] Objects as Keys
From: rowan.collins@gmail.com (Rowan Collins)

Patrick Schaaf wrote on 16/12/2014 11:46:
> Am 16.12.2014 12:36 schrieb "Matteo Beccati" <php@beccati.com>:
>> On 16/12/2014 11:52, Andrea Faulds wrote:
>>> I was previously in favour of this, but it’d prevent actual indexing
>>> by objects in future, and I can’t think of any use cases which aren’t
>>> better solved by explicitly converting to a string/integer.
>> That's precisely the same reason why I voted Nay. And I wouldn't have
> been able to put it down in words better than Andrea did.
>
> That was my thought initially, too. But I think it is wrong. If PHP ever
> gets around to provide objects-themselves-as-array-keys support, it can
> easily do that
>
> 1) only if the object does not have such a __toKey() method, or
> 2) if the object has one, but it returns the object itself (which is
> forbidden now by the RFC)

Hm, that's an interesting thought. My thought had been that an 
object-as-key would need to specify its hash anyway, so that two objects 
of the same "value" would be automatically de-duped, just as two strings 
are. But I guess an internally unique handle for the specific object 
would also be a reasonable approach for some uses.

Perhaps like with Traversable, we could have a set of magic interfaces 
(although I'm struggling to think of names for them, which may be a bad 
sign):

a) an "abstract" base interface meaning "can be used as $bar in 
$foo[$bar]"; like Traversable, this would not actually be implementable 
directly, but be the parent of the following
b) an interface for objects which produce a one-way hash to use as the 
key (as in the current proposal)
c) an interface for objects which can themselves be stored as the key, 
with internally unique handle as identifier
d) an interface for objects which can themselves be stored as the key, 
but with a custom "value" used as the identifier

This sounds complex, but wouldn't necessarily be. (c) is just a special 
case of (d) with an implied default implementation of the value method. 
And if the structure of the HashTable retained the index/key structure 
we have now, but with the object pointer as an additional field, the 
pseudo-code when an object was encountered in array-key context would be:

if $obj has interface (a) then
.   if $obj has interface (c) then
.   .   key := get_internal_identifier($obj)
.   .   else key := $obj->getHash() // this covers (b) and (d)
.   end
.   store value against key
.   if $obj has interface (c) or (d) then store additional pointer to 
original object
else throw error
end

Importantly, the current proposal could be re-cast as an implementation 
of interface (b) while neither promising nor ruling out (c) and/or (d).

-- 
Rowan Collins
[IMSoP]