Re: [RFC][Discussion] NotSerializable attribute

> On Dec 9, 2023, at 4:55 PM, Robert Landers <landers.robert@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.wiki@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