Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121971
MIME-Version: 1.0
References: <CAGgaK7+w_zdp30Pi5nJ-y+GPEkfc2xHfFUW+DwdpNtY8iPjMHg@mail.gmail.com>
 <1BF39851-A294-44D9-827F-933B00807441@automattic.com>
In-Reply-To: <1BF39851-A294-44D9-827F-933B00807441@automattic.com>
Date: Sat, 9 Dec 2023 16:55:45 +0100
Message-ID: <CAPzBOBO+sjJqMFoef7mzGV94wXJdiXWeQbb5eYVqNcOqYtT3Sg@mail.gmail.com>
To: Dennis Snell <dennis.snell@automattic.com>
Cc: Max Semenik <maxsem.wiki@gmail.com>, Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: [RFC][Discussion] NotSerializable attribute
From: landers.robert@gmail.com (Robert Landers)

On Sat, Dec 9, 2023 at 4:32=E2=80=AFPM 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]` w=
ith a new `php.ini` setting?
>
> I=E2=80=99m thinking that almost every class I use, if not every single c=
lass, should not be serialized.
> If PHP had a flag to say =E2=80=9Cprevent all classes from serializing=E2=
=80=9D then I could toggle that flag and
> avoid changing every single one of the potentially thousands of classes i=
n my codebase, and
> I wouldn=E2=80=99t 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 d=
eclare serializability
> support, your classes don=E2=80=99t serialize or unserialize.
>
> That could point to a future where _no_ class serializes _unless_ it impl=
ements `__sleep()`
> and `__wakeup()` or `Serializable`, which seems quite reasonable in my mi=
nd as a tradeoff
> between explicitness and surprise.
>
> Warmly,
> Dennis Snell
>
> > On Dec 9, 2023, at 1:30=E2=80=AFPM, 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 sho=
uld
> > 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().

PS. Please don't forget to bottom post on this list.

Robert Landers
Software Engineer
Utrecht NL