Patrick Schaaf wrote on 16/12/2014 11:46:
Am 16.12.2014 12:36 schrieb "Matteo Beccati" <p...@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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
