> On Dec 9, 2023, at 4:55 PM, Robert Landers <landers.rob...@gmail.com> wrote: > > On Sat, Dec 9, 2023 at 4:32 PM Dennis Snell via internals > <internals@lists.php.net> wrote: >> >> 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 >> > > Hi Dennis! > > The biggest downside for the reverse of #[NotSerializable] is that it > would break almost everything that uses serialize (e.g., WordPress > caching, some Symfony/Doctrine things, SQS transports, etc.). Also, > there is the question of whether this would apply to json_encode() or > just serialize().
Thanks Robert, My idea was that the flag, by default, would preserve the existing behavior. A large codebase could decide to wait to disable serialization until every class is appropriately marked. Either way I guess a large refactor is resolved. With `#[Serializable]` the onus is on making sure that features requiring serialization are marked as such. With `#[NotSerializable]` the onus is on classes (which are not concerned with serialization) to opt-out of something unrelated. The RFC calls this out and it is awkward to implement `__wakeup()` with a throwing exception. `#[Serializable]` takes that a step further in linking the two concepts only where they are related. > > PS. Please don't forget to bottom post on this list. Thank you! > > Robert Landers > Software Engineer > Utrecht NL -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
