Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128996
Precedence: list
MIME-Version: 1.0
References: <CAPqq82sqFy1y77XLu8Kbncg18WNopeJdPrfB+JQ8FWNZ4XpTQg@mail.gmail.com>
 <CAPyj-LBG0nR75AUMXT0XCnpNnPP=T62NYvRQ34yeZpd+i=cTPw@mail.gmail.com>
In-Reply-To: <CAPyj-LBG0nR75AUMXT0XCnpNnPP=T62NYvRQ34yeZpd+i=cTPw@mail.gmail.com>
Date: Wed, 29 Oct 2025 16:35:40 +0200
Message-ID: <CAPqq82sy1O9-J4yhvcPvsob3Rjdi1wFDW_t597850sBTbKc=sg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][Discussion] Add #[NoSerialize] attribute for
 excluding properties or classes from serialization
To: Ilija Tovilo <tovilo.ilija@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: lnkvisitor.ts@gmail.com (Dmytro Kulyk)

Thanks for the feedback!

On Tue, Oct 28, 2025 at 17:47 Ilija Tovilo <tovilo.ilija@gmail.com> wrote:
>
> Hi Dmytro
>
> On Tue, Oct 28, 2025 at 12:00=E2=80=AFAM Dmytro Kulyk <lnkvisitor.ts@gmai=
l.com> wrote:
> >
> > I=E2=80=99d like to open a discussion about a new proposal introducing =
the
> > #[NoSerialize] attribute, which allows developers to explicitly
> > exclude properties =E2=80=94 or even entire classes =E2=80=94 from nati=
ve PHP
> > serialization.
> >
> > RFC: https://wiki.php.net/rfc/no_serialize_attribute
> > Implementation: https://github.com/php/php-src/pull/20074
>
> Thank you for your proposal. I have a few comments.
>
> > When applied to a class, instances will be serialized as NULL.
>
> I don't understand the rationale for diverging from the existing
> @not-serializable behavior of internal classes, which throw when
> attempted to be serialized (e.g. Random\Engine\Secure). I see there's
> also a separate RFC to introduce that behavior:
> https://wiki.php.net/rfc/not_serializable_attribute I don't think
> there's a need for both of these attributes. To demonstrate, how would
> we even decide whether an internal class like PDO should get the
> #[NoSerialize] or #[NotSerializable] attribute? Informing the user of
> potentially incorrect serialization is the prudent option, and if they
> would like to skip the serialization of a property containing a PDO
> object they can simply mark it as #[NoSerialize].
>
> The RFC says:
>
> > This approach ensures that data structures containing such objects (for=
 example, arrays, collections, or parent objects) remain valid and can be s=
afely unserialized without errors, while clearly indicating that the value =
was intentionally omitted.
>
> But is replacing unserializable objects with NULL in nested arrays
> really the safe choice? In these cases, I feel like a custom
> serializer that consciously replaces the object is warranted. This
> might also cause problems for typed properties:
>
>     #[NoSerialize]
>     class PDO {}
>
>     class Foo {
>         /* Will be happily serialized as NULL, but can't be restored beca=
use the
>          * property is not nullable. */
>         public PDO $connection;
>     }
>
> To summarize, I'd prefer if #[NoSerialize] on classes would cause
> serialize() to throw, like we already do for @not-serializable.

You=E2=80=99re absolutely right that the current internal behavior (e.g.
Random\Engine\Secure, CurlHandle, etc.) throws when serialization is
attempted, and that the proposed #[NotSerializable] RFC formalizes
this for userland classes.
The intent behind #[NoSerialize] is not to diverge from that model,
but to provide a softer, complementary mechanism targeting a different
use case =E2=80=94 non-critical, transient classes that can safely degrade =
to
NULL without breaking surrounding data structures.
In this example, PDO (and other resource-backed classes) should indeed
use #[NotSerializable], because serialization is semantically invalid
and must throw.
#[NoSerialize], on the other hand, would apply to wrappers,
containers, or domain objects where serialization of the rest of the
structure should continue even if one field or nested object cannot be
meaningfully serialized.

>
> > Class-level #[NoSerialize] is inherited by child classes unless explici=
tly overridden.
>
> Can you clarify how this would work? How can you override this
> attribute by omission?
>
>     #[NoSerialize]
>     class Foo {}
>
>     /* What do I add here to remove #[NoSerialize]? */
>     class Bar extends Foo {}

Class-level #[NoSerialize] is transparently inherited by child classes.
There=E2=80=99s currently no way to override or cancel this behavior in
descendants; the attribute remains effective throughout the
inheritance chain.


As an alternative, #[NotSerializable] could be extended to
#[NotSerializable(bool $soft =3D false)], which would provide the same
behavior while keeping it in a separate, more consistent attribute =E2=80=
=94
avoiding the double semantics currently implied by #[NoSerialize].

> > Out of scope: JSON (json_encode(), JsonSerializable) and var_export() r=
emain unaffected.
>
> Any future attempt to exclude properties marked as #[NoSerialize] from
> json_encode() would be backwards incompatible after this RFC has been
> implemented. To avoid this BC break, json_encode() would need a
> separate attribute (e.g. #[NoJsonEncode]). That sounds reasonable, but
> should be spelled out in the RFC.

It has been added to section 2.5

> > Invalid Targets & Compile-Time Diagnostics
>
> What's the rationale for warning for some, but erroring for others?

Initially, the idea was to make all of these cases emit warnings, but
I didn=E2=80=99t figure out how to implement that consistently within the
attribute validators.
At this point, I don=E2=80=99t see any practical reason to allow the attrib=
ute
on unsupported targets, so all such cases will be changed to
compile-time errors instead of warnings.

Dmytro