On Wed, Jan 3, 2024, at 7:11 AM, Nicolas Grekas wrote: > Hi Max, > > Hi, I'd like to propose a new attribute, #[NotSerializable]. This >> functionality is already available for internal classes - userspace should >> benefit from it, too. >> >> The RFC: https://wiki.php.net/rfc/not_serializable >> Proposed implementation: https://github.com/php/php-src/pull/12788 >> >> Please let me know what you think. >> > > Regarding the inheritance-related behavior ("The non-serializable flag is > inherited by descendants"), this is very unlike any other attributes, and > this actively prevents writing a child class that'd make a parent > serializable if it wants to. > > To me, if this is really the behavior we want, then the attribute should be > replaced by a maker interface. > Then, a simple "instanceof NotSerializable" would be enough instead of > adding yet another method to ReflectionClass. > > Cheers, > Nicolas
I think I'm inclined to agree with Nicolas. If the intent here is to impact mainly serialize()/unserialize(), then a marker interface seems like it has the desired logic "built in" more than an attribute does. It would only work at the object level, but that seems correct in this case. For excluding individual properties, __serialize()/__unserialize() already support that use case. That's one of the main uses for them. User-space serializers (Crell/Serde, JMS, Symfony, etc.) could easily be modified to honor the interface as well for external serialization. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
