Am 03.01.2024, 20:21:22 schrieb Larry Garfield <[email protected]>:
> 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. > I have to disagree, and would favor this more when it becomes an attribute vs a marker interface. Attributes are precisely there to avoid marker interfaces. And there is no precedent in PHP of something similar that suggests we should use a marker interface. The impact on inheritance is not related to this being an attribute, it is already the behavior of the engine with the ZEND_ACC_NOT_SERIALIZABLE flag, you can’t extend PDO and serialize its decendent for example. Ant there is no way to overwrite that in the child class either. Yes, with an attribute it requires considerably more code to check for serializability in a user-space code, than to check for a Marker interface. But thats not a good enough reason to introduce a new pattern into the language. The same argument could be made to anything related attributes why we added that to reflection and not added „easier functions“. > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
