пт, 7 лист. 2025 р. о 12:57 Tim Düsterhus <[email protected]> пише:
>
> Thank you. The updated RFC is looking good to me. I also appreciate that
> you kept a changelog within the RFC.
>
> One thing you could mention and that should be done as part of the RFC
> is migrating all existing classes with `@not-serializable` to make use
> of the attribute instead. That's also what has been done when the
> `#[\Deprecated]` attribute was introduced. Other than that, I don't have
> any further comments.
>
Thank you for the review and the helpful suggestion.
I agree that all internal classes currently annotated with
@not-serializable should also receive the corresponding
#[\NoSerialize] attribute as part of this RFC. This ensures that
internal metadata, reflection, and userland tooling remain fully
aligned, and that the behavior is consistently exposed at both the
engine and stub levels.
The RFC has been updated to explicitly state that these attributes
will be added for all such internal classes.
I also have one technical question regarding stub generation:
When attributes are emitted into generated arginfo.h files, should the
generator automatically include zend_attributes.h?
This would avoid requiring extensions to include zend_attributes.h
explicitly when they do not use attributes themselves but only include
generated stubs that reference them. Before making any implementation
adjustments, I’d appreciate confirmation that this approach is
acceptable within the current stub-generation design.
```
/* This is a generated file, edit the .stub.php file instead.
* Stub hash: 2fc12d1fde65efbec4305f4934a3f4b25282a552 */
#include "zend_attributes.h"
...
zend_add_class_attribute(class_entry, ZSTR_KNOWN(ZEND_STR_NO_SERIALIZE), 0);
...
```
Best regards,
Dmytro
