Re: [RFC] Reflection for references
| From: | Nicolas Grekas | Date: | Tue, 15 Jan 2019 12:09:17 +0000 |
| Subject: | Re: [RFC] Reflection for references | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-103744@lists.php.net to get a copy of this message | ||
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.