Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78411
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.173 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <544E8AE4.3040907@gmail.com>
References: <544DA1CD.9070109@php.net> <CACQesk7PV2KYnRWmF6wSKUGaXMjnLgvPKFmcJ0UZQroB5iqEZw@mail.gmail.com> <544E8AE4.3040907@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Tue, 28 Oct 2014 00:26:25 +0000
To: PHP Internals <internals@lists.php.net>
Message-ID: <A343627A-7BA6-46EA-A034-50978A48D0DC@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Using objects as keys
From: rowan.collins@gmail.com (Rowan Collins)

On 27 October 2014 18:11:48 GMT, Stas Malyshev <smalyshev@gmail.com> wrote:
>Hi!
>> As others noted, it also prevents a full-fledged objects-as-key
>> implementation in the future.
>You do realize to have such implementation we'd need to rewrite our
>hash
>layer completely and also introduce the concept of immutable object,
>otherwise changing the object would make the hash completely broken?
>Which means it would probably never happen unless PHP engine is
>radically rewritten.

Regarding the immutability, I was wondering if it would be possible to treat the hash not as a magic method but a magic property, and then enforce immutability by saying that it could only be written once in a given instance. Generally speaking, a value or model object would be able to write to it in the constructor, and any incidental changes to the object (e.g. to lazy load data fields) would not affect it.

Potentially, the hash implementation would "only" have to store an object reference next to the existing string (or int) key - all the logic of assigning hash buckets, performing equality checks within buckets, etc, would ignore the object and deal with the scalar value in exactly the same way as if it had been implicitly converted as with the current RFC.

If two non-identical objects with the same hash identity were assigned to the same array, there would have to be a decision of which ended up referenced, but as long as it was defined and documented, I can't see either option being a massive problem.

I realise that when it came down to brass tacks, it would be more complex than I'm implying - the memory impact of adding a pointer field on every key might be a problem, for instance - but it would be good not to dismiss it as impossible too quickly, and use up the syntax for a less powerful feature.

>> In the end it causes issues and brings very little compared to an
>> explicit call to convert an object to a key.
>Same as __toString obviously is useless as you could just call a method
>explicitly.

You're putting words into someone else's mouth there. There's a big difference between "brings very little" and "is useless". There are certainly cases where an implicit call would be useful, but they are probably rather rarer than those where the user would want the object back afterwards.