Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78376
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.123 as permitted sender)
Message-ID: <544DF70D.2040803@sugarcrm.com>
Date: Mon, 27 Oct 2014 00:41:01 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Patrick Schaaf <php@bof.de>
CC: internals <internals@lists.php.net>
References: <544DA1CD.9070109@php.net>	<CAJ26g5SC3VtWU1GnmG7VyaGXjHOMq-N8-0ayASayPNc4EXHuxQ@mail.gmail.com>	<544DEFBE.8090107@sugarcrm.com> <CAJ26g5QzVDMe0wRf-q0xu7_dzDSiF1-rDog9rizs5JVQfY2=6g@mail.gmail.com>
In-Reply-To: <CAJ26g5QzVDMe0wRf-q0xu7_dzDSiF1-rDog9rizs5JVQfY2=6g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Using objects as keys
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> Once your proposal is in the language, you will never, in the future, be
> able to add real support for objects as keys, because the semantics is
> blocked.

This implies this support is not "real" and we want some other support.
I don't think I agree with either.

> I do understand where your proposal is coming from and what it is trying
> to accomplish. But I think, at least, that it should clearly spell out
> that any ambition to really support objects as array keys in the base
> language, will then be given up.

Was there ever such an ambition? Does somebody have any idea how to
properly do it and a reason why?

> I hardly see how that would make sense. SplObjectStorate operates with
> object identity as determined by spl_object_hash, right? Changing that

Now, it does, since there's no other option. However, in the future
there may be other options - i.e. objects whose identity is not the same
as their memory address. For example, for an object representing number
(GMP) or string (UString) their identity is their content, not their
memory address. Thus, if you want to use UString as an index, or have an
unique set of strings, spl_object_hash would not be your friend.
Of course, there's always an option of just telling it - e.g. by
providing an option to the ctor.

> Right. Somehow python manages to live quite fine with that fact.

For some definitions of "quite fine", I presume - I can't see how a
hashtable that repeatedly calls user code can be efficient. It probably
isn't.

> Right. You don't do that when your object implements __hash__ and __eq__.

Or, more precisely, you're asked nicely not to do it - because there's
no way to actually ensure it.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/