Re: Introspection for references
| From: | Nikita Popov | Date: | Tue, 10 Jul 2018 10:30:37 +0000 |
| Subject: | Re: Introspection for references | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-102698@lists.php.net to get a copy of this message | ||
On Tue, Jul 10, 2018 at 12:15 PM, Nicolas Grekas <
nicolas.grekas+php@gmail.com> wrote:
> If we're seeking for a benefit, it would be by turning this to a
>>> ReflectionZval insteaf of ReflectionReference. There would be isRef, but
>>> also getType, etc. But honeslty I'm with you on this, only refs make sense.
>>>
>>
>> I'm wondering if there is any legitimate use for something like this. The
>> only thing that comes to mind is comparing arrays by identity. E.g.
>> https://github.com/symfony/symfony/blob/master/src/Symfony/
>> Component/VarDumper/Cloner/VarCloner.php#L153 could check directly check
>> whether an array is the $GLOBALS array. It would also allow direct
>> recursion detection on arrays (ref
>> https://stackoverflow.com/ques
>> tions/9105816/is-there-a-way-to-detect-circular-arrays-in-pure-php).
>> Doing the same on just references is nearly the same, but doesn't handle
>> the $GLOBALS case correctly.
>>
>
> Note that AFAIK, not only $GLOBALS has a special behavior, but also any
> "scope" array (the deprecated $context argument of error handlers at least,
> maybe what get_defined_vars() also?
>
> If we can return this info, I would definitely leverage it.
> If not, that's no blocker, I'll let you decide.
>
>
>
>> There is a 4th possibility: have a "ReflectionReference::getHash" method,
>>> that would return a unique string/id per reference (what
>>> symfony_zval_debug() does.)
>>>
>>
>> Is this the same as my 3rd suggestion with a different name
>>
>
> No, it's the same, I read too fast.
>
>
>
>> we could return the address hashed with a per-process key. This would
>> make the function somewhat slower though.
>>
>
> That's exactly what we do in our extension, inspired by spl_object_hash().
> On the perf side, a XOR should be OK :)
>
Unfortunately XOR is about as good as just returning the address directly.
XORing the value is basically doing a one-time-pad without the "one-time"
part, aka completely broken. If we wanted to actually hide the address,
we'd have to run it through a proper hash. (Then again, you are right that
spl_object_hash used to do this, so maybe we just don't care...)
Nikita