Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87490
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.48 as permitted sender)
To: Julien Pauli <jpauli@php.net>, PHP Internals <internals@lists.php.net>
References: <CAMUwpuTRzQHqznqKF-q=1Wy-Xnob9mra748E26YiZMKUa7-4DQ@mail.gmail.com>
Message-ID: <55BDBBB5.1000207@gmail.com>
Date: Sat, 1 Aug 2015 23:41:57 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CAMUwpuTRzQHqznqKF-q=1Wy-Xnob9mra748E26YiZMKUa7-4DQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Exposing object handles to userland
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> I've been pinged many times to add a new spl_object_id() function to PHP,
> that would return the internal object handle of an object.

What would be the use of this?

> Today, spl_object_hash() partially allows that, but adds many randomness to
> the result, which is not very cool to use later  (why does it even add
> randomness ?).

So that people would be less inclined to use these hashes as if they
mean something. And to not reveal internal memory details if these IDs
are leaked externally for some reason (which they shouldn't be but sigh...)

> There has been topics about this subject.
> For example, at http://marc.info/?l=php-internals&m=141814350920452&w=2
> 
> 
> Beeing able to get the object handle back in PHP userland would ease many
> tools, mainly debug-oriented tools.

I would say debug tools probably need extensions which can access
internal data structures. Exposing internal data creates bad
dependencies, then we can't fix bugs or refactor stuff because somebody
used internal API in wrong way and now depends on it (like object
unserialization problem where people started using unserialization for
purposes it was never intended to). Let's say in 8.x we remove handles
altogether and replace them with pointers or some other magic? What
these tools would be doing then? By creating this function, we put
values of object IDs (not even their existence, but also their values!)
into public API, which means not we take BC obligations on them. I don't
think it is a good thing.

> I also know people that print_r($an_object) and parse the output just to
> extract the object handle from there... Crazy isn't it ?

Yes, they should not be using object handles for any practical purposes,
it's an implementation detail depending on which is a bad idea.

> Why couldn't we help those people by simply adding a new function that does
> the job ?

I'm not sure that is the job that should be done.

-- 
Stas Malyshev
smalyshev@gmail.com