Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87579
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Nicolas Grekas'" <nicolas.grekas+php@gmail.com>,
	"'Rowan Collins'" <rowan.collins@gmail.com>
Cc: <internals@lists.php.net>
References: <CAMUwpuTRzQHqznqKF-q=1Wy-Xnob9mra748E26YiZMKUa7-4DQ@mail.gmail.com> <CAOWwgp=E_ap59FQ4SJYEMHa6oNbP4s1OhOvMRQnJwYoWhTYk1w@mail.gmail.com> <024101d0cbaa$f864aa50$e92dfef0$@belski.net> <55BDBE25.5050104@gmail.com> <BLU436-SMTP102082244CAF2904DE6FE68E2880@phx.gbl> <55BE5B89.5080103@gmail.com> <CAOWwgpnWgpK59g9czFZMcg4rqY-jPHTTabLDMyYSH+2fJVj=Qg@mail.gmail.com> <4557ED13-5446-45F1-8E04-A01F8A066600@gmail.com> <CAOWwgp=F7HgVtpzGF6nszCJjxwtGLCMqLb9WqPOu3JgDW3XTsw@mail.gmail.com> <EAA99075-3AE8-43CE-A746-FFA1112671EC@gmail.com> <CAOWwgpkcU=X2Hx-OqG624DsncbAERfcvBSQdgutvC84wcj_xeA@mail.gmail.com>
In-Reply-To: <CAOWwgpkcU=X2Hx-OqG624DsncbAERfcvBSQdgutvC84wcj_xeA@mail.gmail.com>
Date: Mon, 3 Aug 2015 16:38:59 +0200
Message-ID: <04cc01d0cdfa$24490e30$6cdb2a90$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQEZxEz2AZ24oXNpNMxONv1anupciAKrx7AyAi9zLxwCa9DPhwIfRl9pAjUtux0AZeGwBgJOG7UjARs9F90Bh7u/cADkj8uTntmfRXA=
Content-Language: en-us
Subject: RE: [PHP-DEV] Exposing object handles to userland
From: anatol.php@belski.net ("Anatol Belski")

Hi Nicolas,

> -----Original Message-----
> From: nicolas.grekas@gmail.com [mailto:nicolas.grekas@gmail.com] On =
Behalf
> Of Nicolas Grekas
> Sent: Monday, August 3, 2015 1:29 PM
> To: Rowan Collins <rowan.collins@gmail.com>
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Exposing object handles to userland
>=20
> > >- more importantly for users, these ids couldn't be compared to
> > >var_dumps'.
> >
> > Why do you need to compare the output of two dump functions? Just =
add
> > a note to the documentation that these are not the same IDs.
> >
>=20
> That's not a strong feature, but still, it makes the tool a little bit =
more
> comfortable to use.
>=20
> Oh, and an other benefit of the handle is that it gives a rough =
estimation of the
> number of objects created and their instantiation order. When =
debugging, any
> hints count.
>=20
> For VarDumper, I don't need spl_objet_id(). As we spotted, the code is =
already
> able to get the number it needs.
>=20
> Having spl_object_id() is still a feature that is not exposed to =
userland, but that is
> useful as I tried to demonstrate.

I'd be on the side of creating new function, too, if it's really needed. =
And not touching the old one. As mentinod before, maybe some other =
useful cases could be addressed like immutable strings.

But with the object id - still, how are the issues mentioned going to be =
handled?

- handle gets reused within the same script, even in same request. =
There's no way to realize an object was garbage collected and completely =
another one has the same id.
- what is done in the case the internal implementation was changed, =
it'll be probably hard to emulate but some apps will already depend on =
it.

Maybe just incrementing a static variable were simple enough :) But IMHO =
these points need to be addressed prior the implementation. Maybe it's =
even not reliable enough to rely on the internal implementation.

Regards

Anatol