Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79795
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.175 as permitted sender)
Message-ID: <5491FE29.1090106@gmail.com>
Date: Wed, 17 Dec 2014 22:05:29 +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> <alpine.DEB.2.11.1412171204040.4080@whisky.home.derickrethans.nl> <CAFp73Xtk5yTEWhWoaVndXDp09BisPfACPu7ucaX4DQiPaYZ4gg@mail.gmail.com> <CACQesk6GTq0z017_9HvZu5VmUeOABH1gdxYdKKShgEDVxS0DXA@mail.gmail.com> <5491B77A.4020004@gmail.com>
In-Reply-To: <5491B77A.4020004@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][VOTE] Objects as Keys
From: rowan.collins@gmail.com (Rowan Collins)

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]