Re: [RFC][VOTE] Objects as Keys

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]