Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78476
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.27 cause and error)
Message-ID: <54527E7E.2020505@garfieldtech.com>
Date: Thu, 30 Oct 2014 13:07:58 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.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>
In-Reply-To: <51CF9ADE-2E04-4BC0-9E5C-B93498251F59@php.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Using objects as keys
From: larry@garfieldtech.com (Larry Garfield)



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