On Thu, 5 Sep 2024, at 17:03, John Coggeshall wrote: > I would suggest we take a step back from this and look at it with a bit more > of a wider lens. It seems to me that this would be a good place to have an > attribute (e.g. `#[NotSerializable]` ) that could be defined for any class > (with `ZEND_ACC_NOT_SERIALIZABLE` being automatically given this attribute)? > It just seems to be a more holistic approach that makes sense, rather than > basing it on internal engine stuff and/or limiting it to internal objects.
It's really the opposite: if we had an attribute, it would be used to toggle the existing internal flag. `ZEND_ACC_NOT_SERIALIZABLE` is just one of a long list of class, property and method flags which the engine uses internally. You can see the full list here: https://heap.space/xref/php-src/Zend/zend_compile.h?r=58aa6fc8#212 You'll notice that includes things like "final" and "private", which refer to straight-forward syntax in the language, as well as completely internal details like "preloaded". It also includes ZEND_ACC_ALLOW_DYNAMIC_PROPERTIES, which is the flag set if you add the #[AllowDynamicProperties] attribute on a class: https://heap.space/xref/php-src/Zend/zend_attributes.c?r=5a18279b#validate_allow_dynamic_properties So if we had a #[NotSerializable] attribute (which I agree might be a good idea) it would be implemented by setting the `ZEND_ACC_NOT_SERIALIZABLE flag on a class definition, and `if this RFC passes, it would automatically apply to json_encode() as well as serialize(). Regards, -- Rowan Tommins [IMSoP]
