Initial ReflectionReference implementation

[nikic]

Implementation of ReflectionReference based on the discussion in https://externals.io/message/102638. Currently the class definition is

final class ReflectionReference {
    /* Returns ReflectionReference if array element is a reference, null otherwise. */
    public static function fromArrayElement(array $array, int|string $key): ?ReflectionReference;
    /* Returns unique identifier for the reference. The return value format is unspecified. */
    public function getId(): int|string;

    private function __construct(); // Always throws
    private function __clone(); // Always throws
}

The return value of getId() uniquely identifies the reference for the duration of its lifetime. An ID may be reused if the reference is destroyed. The format of the return value is unspecified any may change. Only the fact that it will be an integer or string is guaranteed.

In the current implementation the address of the reference is directly returned as the ID. We should be hiding the address here, possibly by hashing it with a secret key. the ID is a raw SHA1 hash of the reference address and a per-process key. Raw meaning 20 character binary data, no hex encoding.

[nikic]

/cc @nicolas-grekas

[nicolas-grekas]

Thanks, I'll definitely check this PR!

[nikic]

@sarciszewski Any tips on how to return scrambled memory addresses, for the getId() function? I could run the address through sha1 together with a per-process secret key, but I'd prefer something more lightweight. A fast 64-bit cipher would probably be ideal here.

[php-pulls]

Comment on behalf of petk at php.net:

Labelling

[nicolas-grekas]

Should the class implements Reflector for consistency with other reflection-related classes?
Should it throw on serialize?
(maybe that's already the case btw, in which case sorry for asking)

[nikic]

Should the class implements Reflector for consistency with other reflection-related classes?

Not if we can avoid it :) Reflector is quite the abomination and should really be removed entirely... I'd prefer not to have implicit stringification on this class just to satisfy this interface. Thankfully there is precedent in not implementing Reflector in the form of ReflectionGenerator.

Should it throw on serialize?

Yes it should! I've made serialize throw for all other reflection classes a while ago, but forgot it here...

[nikic]

Serialization is now properly forbidden.

[nikic]

RFC accepted, merged as 6347f0b.