Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103860
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>
 <CAOWwgpmU6MnHhOKony-R0U_2tiDqS2Pm75G0UFWV+Wg=U1Uesg@mail.gmail.com> <CAF+90c-_KjJd6bOq-yVMAtLV7PSet-qiqnxYSJnjrFxCQcgvHg@mail.gmail.com>
In-Reply-To: <CAF+90c-_KjJd6bOq-yVMAtLV7PSet-qiqnxYSJnjrFxCQcgvHg@mail.gmail.com>
Date: Mon, 28 Jan 2019 10:22:41 +0100
Message-ID: <CAF+90c83_1z58DhfH=U95VLG7Yo1KLDOuEPAiwp13DuEbyKGHw@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e483c3058081386e"
Subject: Re: [PHP-DEV] [RFC] Reflection for references
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000e483c3058081386e
Content-Type: text/plain; charset="UTF-8"

On Tue, Jan 15, 2019 at 1:42 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Tue, Jan 15, 2019 at 1:09 PM Nicolas Grekas <
> nicolas.grekas+php@gmail.com> wrote:
>
>> 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.
>>
>
> A XORed int is not much better than returning the address directly -- it
> will scramble the base address, but for example not the offsets between the
> references (if the XOR key is the same).
>
> If people think that this is good enough for us, then of course it's
> better to go with the int for performance reasons. I've picked the sha1
> here to be conservative. How performance critical is this API?
>
> Nikita
>

I'd like to move forward with the RFC as is -- I'm uncomfortable with
switching this to a simple XOR for security reasons. I think we should
start off with the current implementation, with the option of switching to
an integer return value at a later time.

Nikita

--000000000000e483c3058081386e--