Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121979
MIME-Version: 1.0
References: <CAGgaK7+w_zdp30Pi5nJ-y+GPEkfc2xHfFUW+DwdpNtY8iPjMHg@mail.gmail.com>
 <54BE3A8E-046E-495E-B371-CCF917B6BB49@gmail.com> <CAFPFaMJJArei97Lgqqtk9FH3PcYcMy0__6aTpfdgmYVBJGY93w@mail.gmail.com>
In-Reply-To: <CAFPFaMJJArei97Lgqqtk9FH3PcYcMy0__6aTpfdgmYVBJGY93w@mail.gmail.com>
Date: Sun, 10 Dec 2023 19:49:19 +0300
Message-ID: <CAGgaK7JFE8u9MmprRygi29fHd9yT7WiPhE-wpbgrdNdYS9ws8A@mail.gmail.com>
To: "G. P. B." <george.banyard@gmail.com>
Cc: Rowan Tommins <rowan.collins@gmail.com>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000f98991060c2a991c"
Subject: Re: [PHP-DEV] [RFC][Discussion] NotSerializable attribute
From: maxsem.wiki@gmail.com (Max Semenik)

--000000000000f98991060c2a991c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Dec 9, 2023 at 7:18=E2=80=AFPM Niels Dossche <dossche.niels@gmail.c=
om>
wrote:

> If you instead put #[NotSerializable] on the parent class MyClass, then
> the child class won't be serializable even if you implement the
> serialization methods in the child.
> Is this intentional? If yes, this should probably be clarified in the tex=
t.


Elaborated about the inheritance in the RFC and added a test around it in
the PR.

On Sat, Dec 9, 2023 at 7:29=E2=80=AFPM Larry Garfield <larry@garfieldtech.c=
om>
wrote:

> My main concern is that, as noted, *most* classes probably aren't
> realistically serializable.  Basically any service class should never be
> serialized, ever, and anything that depends on a service class should nev=
er
> be serialized, ever.  So for this attribute to have the desired effect, i=
t
> would need to be added to most classes in a codebase.  Which seems... lik=
e
> a lot of work.  In an ideal world serializability would be opt-in, but we
> do not live in that world.
>

Indeed, adding it to every service would be an annoying overkill, but I
wanted to use it on classes that should *really* not be (de)serialized.

On Sun, Dec 10, 2023 at 2:46=E2=80=AFAM G. P. B. <george.banyard@gmail.com>=
 wrote:

> Moreover, having this as an attribute means, that even without adding a n=
ew
>
method to ReflectionClass, you could determine via Reflection if this class
> is serializable or not.
> Because currently, the only way to know if it is *actually* serializable =
is
> to call serialize() on the object and see what happens.
>

I've amended the RFC with proposed ReflectionClass additions.

--=20
Best regards,
Max Semenik

--000000000000f98991060c2a991c--