Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121978
MIME-Version: 1.0
References: <CAGgaK7+w_zdp30Pi5nJ-y+GPEkfc2xHfFUW+DwdpNtY8iPjMHg@mail.gmail.com>
 <54BE3A8E-046E-495E-B371-CCF917B6BB49@gmail.com>
In-Reply-To: <54BE3A8E-046E-495E-B371-CCF917B6BB49@gmail.com>
Date: Sat, 9 Dec 2023 23:46:02 +0000
Message-ID: <CAFPFaMJJArei97Lgqqtk9FH3PcYcMy0__6aTpfdgmYVBJGY93w@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000062186e060c1c4e3c"
Subject: Re: [PHP-DEV] [RFC][Discussion] NotSerializable attribute
From: george.banyard@gmail.com ("G. P. B.")

--00000000000062186e060c1c4e3c
Content-Type: text/plain; charset="UTF-8"

The implementation is simple and straight to the point, and uses machinery
that has been added to the engine to deal more consistently with internal
classes.

In an ideal world (IMHO) serialization would be opt-in and __serialize()
would be used to enable and describe the serialization format.
However, this is not the case, and IMHO implementing __serialize() should
only be done to change the *default* serialization format *not* to disable
it.

Exposing this to userland makes sense, as this would prevented the mess
that was the Serializable interface that people used to disable
serialization which was less then ideal.

Moreover, having this as an attribute means, that even without adding a new
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.


On Sat, 9 Dec 2023 at 17:16, Rowan Tommins <rowan.collins@gmail.com> wrote:

> On 9 December 2023 12:30:29 GMT, 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.
>
> If this ends up approximately the same as implementing serialisation as an
> exception, it feels quite a thin feature. If you put __sleep and __wakeup
> as shown into a trait, it's already as short and explicit as "use
> NotSerializable;"
>

If the alternative solution is a trait, then it is, IMHO, a bad alternative
solution.

What would make it more compelling is if the engine itself could do more
> with the attribute. For instance, a direct isSerializable() on
> ReflectionClass that covered both internal and attribute-marked classes.
>

I do agree, adding a isSerializable() function to ReflectionClass is a good
idea.

Best regards,

Gina P. Banyard

--00000000000062186e060c1c4e3c--