Max, I love this idea. Would it make sense to flip the design though and add `#[Serializable]` with a new `php.ini` setting?
I’m thinking that almost every class I use, if not every single class, should not be serialized. If PHP had a flag to say “prevent all classes from serializing” then I could toggle that flag and avoid changing every single one of the potentially thousands of classes in my codebase, and I wouldn’t have to worry about ensuring that everyone creating a new class remembers to add this attribute. For existing sites with serializable classes we can leave the default of this new flag to the permissive legacy behavior: every class is serializable. However, if you are willing and have vetted your code you can flip that flag and now _unless_ you explicitly declare serializability support, your classes don’t serialize or unserialize. That could point to a future where _no_ class serializes _unless_ it implements `__sleep()` and `__wakeup()` or `Serializable`, which seems quite reasonable in my mind as a tradeoff between explicitness and surprise. Warmly, Dennis Snell > On Dec 9, 2023, at 1:30 PM, Max Semenik <maxsem.w...@gmail.com> wrote: > > 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. > > -- > Best regards, > Max Semenik > > --0000000000006c4879060c12de83-- > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
