Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78381
Return-Path: <mike.php.net@gmail.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 21233 invoked from network); 27 Oct 2014 08:35:07 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 27 Oct 2014 08:35:07 -0000
Authentication-Results: pb1.pair.com smtp.mail=mike.php.net@gmail.com; spf=pass; sender-id=pass
Authentication-Results: pb1.pair.com header.from=mike.php.net@gmail.com; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.175 as permitted sender)
X-PHP-List-Original-Sender: mike.php.net@gmail.com
X-Host-Fingerprint: 209.85.212.175 mail-wi0-f175.google.com  
Received: from [209.85.212.175] ([209.85.212.175:33376] helo=mail-wi0-f175.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id E7/9A-56216-BB30E445 for <internals@lists.php.net>; Mon, 27 Oct 2014 03:35:07 -0500
Received: by mail-wi0-f175.google.com with SMTP id h11so3609261wiw.2
        for <internals@lists.php.net>; Mon, 27 Oct 2014 01:35:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        bh=XvAkvPzOusi3Labj5aHNV5pApvDjSxzlZgYPxici8pg=;
        b=xXSSa5N6DjJE6NGVJOns3h4rgyRKWrmOSK0R/Z3dc2koGccE9bhKvSV+5zw8qt51b3
         NsdweJoef8MaEQerbkQgOXBsC8nsDfX49xxCMgBN6uli+il/B0quU62xjDifsIYZwOP6
         PQyOeAz1J3EJUUX9xiVutFNAa4Yz6kyqax6z2somPrIUhlzmWyIKsiKu1wGWPMzhbdJ/
         dnN2QxUzKNk1rGrV60IHcpyNyhw4fgmAOSd5iV0pLtBY+Hd/gFFIvL1THrc8X0aat4s3
         coUClrH5QJktGajDmRNX9tMkBlS91srL0xDELD8beZLBbp2r5hFLd/HEWzanD3e0fR7p
         E2Vg==
X-Received: by 10.194.77.199 with SMTP id u7mr1446027wjw.92.1414398904702;
        Mon, 27 Oct 2014 01:35:04 -0700 (PDT)
Received: from [192.168.1.163] (95-143-224-254.customer.bnet.at. [95.143.224.254])
        by mx.google.com with ESMTPSA id gm9sm11045257wib.18.2014.10.27.01.35.03
        for <multiple recipients>
        (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Mon, 27 Oct 2014 01:35:03 -0700 (PDT)
Sender: Michael Wallner <mike.php.net@gmail.com>
Message-ID: <544E03B6.5030707@php.net>
Date: Mon, 27 Oct 2014 09:35:02 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Will Fitch <willfitch@php.net>, Stas Malyshev <smalyshev@gmail.com>
CC: PHP Internals <internals@lists.php.net>
References: <544DA1CD.9070109@php.net> <A7DB3F27-0306-4401-919A-006000A5C164@fitch.so> <544DB15E.7090704@php.net> <4F8CEEE9-33CF-4138-9280-5488992C4AAB@php.net>
In-Reply-To: <4F8CEEE9-33CF-4138-9280-5488992C4AAB@php.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Using objects as keys
From: mike@php.net (Michael Wallner)

On 27/10/14 04:08, Will Fitch wrote:
> 
>> On Oct 26, 2014, at 9:43 PM, Stas Malyshev <smalyshev@gmail.com>
>> wrote:
>> 
>> Hi!
>> 
>>> I’m trying to wrap my head around a real-world use-case with
>>> this. We have spl_object_hash, which effectively provides a
>>> unique hash for
>> 
>> This hash has nothing to do with object's contents. But imagine
>> number GMP("42") and imagine you actually want two GMP objects
>> expressing "42" actually represent the same hash key. Or imagine
>> you want to generate the key somehow in a way related to object's
>> content and not just a random number. As I said in the RFC,
>> evidence that so many languages implement it shows that this use
>> case is quite real. Of course, you can always default to
>> spl_object_hash, but now you have control over it.
> 
> Thank you for your clarity. With this new approach, wouldn’t we best
> be served by renaming/deprecating/removing spl_object_hash? I’m
> concerned these different approaches will introduce quite a bit of
> confusion with object hashing. This RFC’s approach gives the user
> more power to determine what’s best in this case, so I’d lean more
> towards renaming spl_object_hash to something that reflects getting a
> unique ID per object (e.g. spl_unique_object_id, etc).

Actually, I see spl_object_hash($this) the 90% implementation of
__hash(), so how about making it the default for any object?

-- 
Regards,
Mike