Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78375
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain bof.de designates 80.242.145.70 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <544DEFBE.8090107@sugarcrm.com>
References: <544DA1CD.9070109@php.net>
	<CAJ26g5SC3VtWU1GnmG7VyaGXjHOMq-N8-0ayASayPNc4EXHuxQ@mail.gmail.com>
	<544DEFBE.8090107@sugarcrm.com>
Date: Mon, 27 Oct 2014 08:22:56 +0100
Message-ID: <CAJ26g5QzVDMe0wRf-q0xu7_dzDSiF1-rDog9rizs5JVQfY2=6g@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c120e45433b005066266ea
Subject: Re: [PHP-DEV] [RFC] Using objects as keys
From: php@bof.de (Patrick Schaaf)

--001a11c120e45433b005066266ea
Content-Type: text/plain; charset=UTF-8

Am 27.10.2014 08:09 schrieb "Stas Malyshev" <smalyshev@sugarcrm.com>:
>
> > I don't like this, mainly because it blocks a future direct use and
storage
> > of objects as keys in an array, i.e. what SplObjectStorage does.
>
> It does not. It just allows the objects to control how they are seen
> when they are used as keys in regular PHP arrays. That does not prevent
> SplObjectStorage or anything else from doing whatever one wants.

I did not mean SplObjectStorage would be affected negatively. Just used it
as the best known example for something that directly supports objects
themselves as keys.

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.

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.

> I personally would say SplObjectStorage probably should respect __hash if
> provided, but we can discuss it separately.

I hardly see how that would make sense. SplObjectStorate operates with
object identity as determined by spl_object_hash, right? Changing that to
use your key derivation method, would break that contract. Okay, maybe it
could make sense by adding a second set of attach/detach methods that work
this way when the objects support the new hash method.

> Storing objects in the hashtable would really require rewriting the whole
> hashtable and would probably be very inefficient as you'd have to call
> PHP code each time you compare two objects in the chain.

Right. Somehow python manages to live quite fine with that fact.

> Moreover, modifying such objects would probably create havoc.

Right. You don't do that when your object implements __hash__ and __eq__.

best regards
  Patrick

--001a11c120e45433b005066266ea--