Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121972
Reply-To: Dennis Snell <dennis.snell@automattic.com>
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\))
In-Reply-To: <CAPzBOBO+sjJqMFoef7mzGV94wXJdiXWeQbb5eYVqNcOqYtT3Sg@mail.gmail.com>
Date: Sat, 9 Dec 2023 17:00:52 +0100
Cc: Max Semenik <maxsem.wiki@gmail.com>,
 Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <186E7CDC-92D4-4A33-9B1A-8B8624B8E54B@automattic.com>
References: <CAGgaK7+w_zdp30Pi5nJ-y+GPEkfc2xHfFUW+DwdpNtY8iPjMHg@mail.gmail.com>
 <1BF39851-A294-44D9-827F-933B00807441@automattic.com>
 <CAPzBOBO+sjJqMFoef7mzGV94wXJdiXWeQbb5eYVqNcOqYtT3Sg@mail.gmail.com>
To: Robert Landers <landers.robert@gmail.com>
Subject: Re: [PHP-DEV] [RFC][Discussion] NotSerializable attribute
From: internals@lists.php.net ("Dennis Snell via internals")


> On Dec 9, 2023, at 4:55=E2=80=AFPM, Robert Landers =
<landers.robert@gmail.com> wrote:
>=20
> On Sat, Dec 9, 2023 at 4:32=E2=80=AFPM Dennis Snell via internals
> <internals@lists.php.net> wrote:
>>=20
>> Max, I love this idea.
>>=20
>> Would it make sense to flip the design though and add =
`#[Serializable]` with a new `php.ini` setting?
>>=20
>> I=E2=80=99m thinking that almost every class I use, if not every =
single class, 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 in my codebase, and
>> I wouldn=E2=80=99t have to worry about ensuring that everyone =
creating a new class remembers to add
>> this attribute.
>>=20
>> 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=E2=80=99t serialize or unserialize.
>>=20
>> 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.
>>=20
>> Warmly,
>> Dennis Snell
>>=20
>>> On Dec 9, 2023, at 1:30=E2=80=AFPM, Max Semenik =
<maxsem.wiki@gmail.com> wrote:
>>>=20
>>> Hi, I'd like to propose a new attribute, #[NotSerializable]. This
>>> functionality is already available for internal classes - userspace =
should
>>> benefit from it, too.
>>>=20
>>> The RFC: https://wiki.php.net/rfc/not_serializable
>>> Proposed implementation: https://github.com/php/php-src/pull/12788
>>>=20
>>> Please let me know what you think.
>>>=20
>>> --
>>> Best regards,
>>> Max Semenik
>>>=20
>>> --0000000000006c4879060c12de83--
>>>=20
>>=20
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: https://www.php.net/unsub.php
>>=20
>=20
> Hi Dennis!
>=20
> 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.

>=20
> PS. Please don't forget to bottom post on this list.

Thank you!

>=20
> Robert Landers
> Software Engineer
> Utrecht NL