Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103744
MIME-Version: 1.0
References: <CAF+90c-V9vG8eAanQgujb+GhkLWtH2N0VRe500oocNQ7ryfb=Q@mail.gmail.com>
 <CADyq6s+qnFfZGMfr0HfyW6Qu9MC+_M_h3mQDOiDMJzWWTVHE-Q@mail.gmail.com> <CAF+90c8u0Qn2+xJBpae+7YGBSXeaw_7RdZ6Ym7Q_R48ZWA7pLQ@mail.gmail.com>
In-Reply-To: <CAF+90c8u0Qn2+xJBpae+7YGBSXeaw_7RdZ6Ym7Q_R48ZWA7pLQ@mail.gmail.com>
Date: Tue, 15 Jan 2019 13:09:17 +0100
Message-ID: <CAOWwgpmU6MnHhOKony-R0U_2tiDqS2Pm75G0UFWV+Wg=U1Uesg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000876b0b057f7e08ed"
Subject: Re: [PHP-DEV] [RFC] Reflection for references
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000876b0b057f7e08ed
Content-Type: text/plain; charset="UTF-8"

About using "int" as return type for getId():

>  * Can the `getId()` return type be restricted to either `int` or
> > `string`? Why is it a union type right now? Technical limitation?
>
> To allow changes in the future. The real return value here is an int, but
> the size increase due to hashing makes it a string. If we find a way to
> avoid that (or decided that we don't care about leaking addresses), we
> could change this to a (faster) int-based API.
>

spl_object_hash() uses a XOR to hide internal addresses - so they're
already "leaking".
we also added spl_object_id() which proved much better in term of memory
usage - not only CPU.

Mixing both arguments/approaches, what about returning a XORed int? Are we
OK with that? It'd be a welcome storage/CPU optimization from my pov.

--000000000000876b0b057f7e08ed--