Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129003
Precedence: list
MIME-Version: 1.0
References: <CAPqq82sqFy1y77XLu8Kbncg18WNopeJdPrfB+JQ8FWNZ4XpTQg@mail.gmail.com>
 <CAPyj-LBG0nR75AUMXT0XCnpNnPP=T62NYvRQ34yeZpd+i=cTPw@mail.gmail.com>
 <CAPqq82sy1O9-J4yhvcPvsob3Rjdi1wFDW_t597850sBTbKc=sg@mail.gmail.com> <4b6abc36d8ab6cd306e95141869db3b0@bastelstu.be>
In-Reply-To: <4b6abc36d8ab6cd306e95141869db3b0@bastelstu.be>
Date: Thu, 30 Oct 2025 00:23:05 +0200
Message-ID: <CAPqq82u7xhMDqmwuhEPOGqHdnrM3S2OM+HG=XpG-SyKPS3LofA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][Discussion] Add #[NoSerialize] attribute for
 excluding properties or classes from serialization
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: Ilija Tovilo <tovilo.ilija@gmail.com>, 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.

> Thank you for your RFC. It is really well-written and nicely explains
> the various (edge) cases. I've only read through the `#[\NoSerialize]`
> one, since it is the topic of this RFC discussion. I agree with Ilija on
> all points.
>
> Am 2025-10-29 15:35, schrieb Dmytro Kulyk:
> > #[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.
>
> But even for wrappers you can't guarantee that the wrapper is stored in
> a nullable property. When applying the attribute to a field, omitting
> the field makes sense, since the author of the property is the same
> person who is capable of adding the attribute and thus is in full
> control. This is different for classes where the author of the class
> doesn't know how and where the class is being used. I thus agree with
> Ilija that this should throw to clearly indicate that the user of the
> class is doing something incorrect and to not silently corrupt data. If
> an author of a class needs more fine-grained control, they can either
> add the attribute to individual properties themselves - or implement
> `__serialize()`.
>

You are right, this behavior can be non-obvious and lead to unexpected resu=
lts.

> >> > Class-level #[NoSerialize] is inherited by child classes unless expl=
icitly 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.
>
> Indeed, however the =E2=80=9Cunless explicitly overridden=E2=80=9D bit in=
 the RFC text
> implies that this is possible.
>
> > 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].
>
> I don't think that sub classes should be able to make a non-serializable
> parent class serializable, since they clearly won't be able to correctly
> restore the state of the parent class. In fact I would consider this an
> improvement over the existing serialization hooks where the child class
> can simply skip calling the parent's serializer and thus create a
> situation that the parent class does not expect to occur.

It already makes no sense because the class-level attribute will be
excluded from the RFC, and I have no plan to add something like this
to #[NotSerializable]. It may be added in a future RFC.

> > 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 t=
he
> > attribute validators.
> > At this point, I don=E2=80=99t see any practical reason to allow the at=
tribute
> > on unsupported targets, so all such cases will be changed to
> > compile-time errors instead of warnings.
>
> Yes, every clear error that is detectable at compile-time should be a
> hard error to make it easy for users to detect the mistake.
>

Best regards
Dmytro Kulyk