Am 03.01.2024, 20:21:22 schrieb Larry Garfield <larry@garfieldtech.com>:
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.
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