Re: [RFC] [Discussion] Serializable closures from constant expressions
| From: | Tim Düsterhus | Date: | Wed, 08 Jul 2026 19:39:56 +0000 |
| Subject: | Re: [RFC] [Discussion] Serializable closures from constant expressions | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-131821@lists.php.net to get a copy of this message | ||
Hi
On 2026-07-04 11:02, Nicolas Grekas wrote:
I'd also be fine with a limited version of this RFC that'd remove the serialize-related part and that'd keep only the proposed Reflection-based API. This is the very core where engine support is needed. The serialize part would make attributes work seamlessly with backends that use serialize(), but my use cases build on the deepclone/VarExporter extension/components, and those need only reflection. In case that can help bring a broader consensus.As indicated in my previous email, I'm also concerned about the Reflection-based API and don't consider it good language design. Given that the Reflection-based API needs Reflection and the specific constraint of “the serialized payload is only valid until the next deployment”, I also don't see how it would enable anything that you can't already do. - For public first class callables, just generate a first class callable. - For private and protected ones generate `(new ReflectionMethod($class, $method))->getClosure()`. - For full Closures generate the the appropriate Reflection chain accessing the right Closure, e.g. `(new ReflectionProperty($class, $method))->getAttributes()[$attrNo]->getArguments()[$argumentNo]`. The proposed new API would effectively do the same, and then add the extra safety checks that you, from what I understand, wouldn't need for this use case. Best regards Tim Düsterhus