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
