Re: [RFC][Discussion] NotSerializable attribute
| From: | Dennis Snell via internals | Date: | Sat, 09 Dec 2023 15:31:59 +0000 |
| Subject: | Re: [RFC][Discussion] NotSerializable attribute | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-121970@lists.php.net to get a copy of this message | ||
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--
>