On 17/12/2014 17:03, Stanislav Malyshev wrote:
Hi!
As I said in the original discussion: this RFC is actually about having
an implicit call to __hash() whenever an object is used as an array key.
You can achieve exactly the same in userland with an explicit call.
It's like nobody have ever seen __toString before... Of course you can
do that 10-line boilerplate that Rowan outlined. The whole point of this
RFC is so you don't have to do the boilerplate.
Just to clarify, I in no way wanted to say that reducing that
boilerplate was not a good thing. I was responding to the concept that
this allows things which weren't previously possible. I definitely think
syntactic sugar can be a good thing, and can see the advantage of this
proposal.
I would rather wait (maybe indefinitely) to have a proper implementation
of objects as keys than have this compromise.
I have hard time to understand this - it's like somebody offering to
give you $100, with no conditions, and you say "no, I'd rather wait for
somebody giving me a billion dollars, until then I won't take the $100".
Having object as keys does not contradict this RFC in any way - though
the probability of it happening in PHP 7 is pretty much nil so you'd
have to wait at least several years, but most probably - forever. So you
pretty much choosing to have nothing over having something with no
upside at all. Why?
Yes, there are versions of objects-as-keys which are compatible with
this proposal; however, there are also versions which are not.
For instance, without this proposal we could implement something so that
*for any object*, $foo[$obj] = 42 stores the object as the key. If this
RFC is already in place, then any object which uses __hash (or whatever
name we give it) to return a scalar key cannot also be used in that way.
That may not be a big deal - the creator of the object can choose which
behaviour to use - but the creator of the containing structure couldn't,
which might be a nuisance.
I guess the other way in which it reduces the chance of a more
"complete" solution is a psychological one - once this is in there, the
number of cases that need object-as-key support will be even lower,
leaving those that aren't served by this version less likely to be
approached.
I'm on the fence on this one. For one thing, I think it might be
interesting to explore whether real objects as keys is actually as
difficult as some people are assuming. I can naively imagine a few ways
it could be implemented that seem in my mind to have minimal impact on
any array that doesn't use it, but haven't yet seen anyone seriously
discuss any possible approaches.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
