Re: RFC: Deprecate json_encode() on classes marked as non-serializable

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]