Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78377
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.212.173 cause and error)
Message-ID: <1414396519.2624.149.camel@localhost.localdomain>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Patrick Schaaf <php@bof.de>, internals <internals@lists.php.net>
Date: Mon, 27 Oct 2014 07:55:19 +0000
In-Reply-To: <544DF70D.2040803@sugarcrm.com>
References: <544DA1CD.9070109@php.net>
		<CAJ26g5SC3VtWU1GnmG7VyaGXjHOMq-N8-0ayASayPNc4EXHuxQ@mail.gmail.com>
		<544DEFBE.8090107@sugarcrm.com>
	 <CAJ26g5QzVDMe0wRf-q0xu7_dzDSiF1-rDog9rizs5JVQfY2=6g@mail.gmail.com>
	 <544DF70D.2040803@sugarcrm.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Using objects as keys
From: pthreads@pthreads.org (Joe Watkins)

On Mon, 2014-10-27 at 00:41 -0700, Stas Malyshev wrote:
> 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/
> 

Morning,

	As already pointed out by Stas, using objects as array keys would
require a rewrite of the HashTable API, something integral to PHP.

	I'm not sure that is realistic, or possible.

	I think probably, the best way we can support objects as collection
keys is with the introduction of generics, something totally
disconnected from this RFC, that nobody has a working patch for.

Cheers
Joe