Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78481
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.176 as permitted sender)
Message-ID: <54528485.7080600@gmail.com>
Date: Thu, 30 Oct 2014 18:33:41 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <544DA1CD.9070109@php.net> <CAEbg-4YmUzuAEJZOqqCC=vJ=XY5b7HCZnj25B_JYxu1XJof_YQ@mail.gmail.com> <4ED7146272E04A47B986ED49E771E347BD7E35E061@Ikarus.ameusgmbh.intern> <51CF9ADE-2E04-4BC0-9E5C-B93498251F59@php.net> <54527E7E.2020505@garfieldtech.com>
In-Reply-To: <54527E7E.2020505@garfieldtech.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Using objects as keys
From: rowan.collins@gmail.com (Rowan Collins)

Larry Garfield wrote on 30/10/2014 18:07:
>
>
> On 10/30/14, 2:19 AM, Will Fitch wrote:
>>
>>> On Oct 30, 2014, at 2:13 AM, Christian Stoller <stoller@leonex.de> 
>>> wrote:
>>>
>>>
>>> From: Alexander Lisachenko [mailto:lisachenko.it@gmail.com], Sent: 
>>> Monday, October 27, 2014 11:18 AM
>>>
>>>> Hello, internals!
>>>>
>>>>> The name __hash is not final, I am open to using __toKey instead 
>>>>> or any
>>>>> reasonable alternative, we may also include a couple of options in 
>>>>> the
>>>>> vote if that will be a point of disagreement.
>>>>
>>>> I like this idea with custom hash implementation because 
>>>> spl_object_hash()
>>>> is not reliable when objects are quickly created/destroyed, so 
>>>> hashes can
>>>> be the same for several different objects. However, will it be 
>>>> better to
>>>> introduce an interface for that? For example, Hashable can be a 
>>>> good name
>>>> (like Traversable one). Default implementation then can be a simple 
>>>> trait
>>>> that will be added later to the concrete class.
>>>
>>>
>>> I like the idea introducing an interface for this functionality, 
>>> instead
>>> of adding a further magic method. But I think anything like "hash" or
>>> "hashable" is confusing for users.
>>
>> The magic method is more of a PHP approach while an interface would 
>> be more appropriate.  That said, this RFC is a true representation of 
>> a hash vs something like spl_object_hash. That’s what causes user 
>> confusion.  spl_object_hash would’ve been better served as a name 
>> like spl_object_id or spl_object_hash_id.  Something that indicates 
>> uniqueness regardless of the values of a particular object.
>
> Put another way, I think a key question here is:
>
> class Foo {
>   public $bar;
> }
>
> $a = new Foo;
> $a->bar = 'baz';
> $b = new Foo;
> $b->bar = 'baz';
>
> $arr[$a] = true;
> $arr[$b] = true;
>
>
> Does $arr now contain one value or two?
>
> If the desire is for it to contain 2, then spl_object_hash($a) already 
> has that covered, I think.
>
> If the desire is for it to contain 1, then the proposal sounds like a 
> way to normalize Foo::stringifiedValueObjectEquivalent().
>
> --Larry Garfield
>

The desire is for the author of Foo to be able to choose which behaviour 
is appropriate for them.

-- 
Rowan Collins
[IMSoP]