Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129014
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> <CAPqq82u7xhMDqmwuhEPOGqHdnrM3S2OM+HG=XpG-SyKPS3LofA@mail.gmail.com>
 <21ff8dee5016a1b7ecc412c44233abd1@bastelstu.be>
In-Reply-To: <21ff8dee5016a1b7ecc412c44233abd1@bastelstu.be>
Date: Fri, 31 Oct 2025 00:24:09 +0200
Message-ID: <CAPqq82vPdraqE1DuJQ6w4pWpwr1koTHcj_o0pKV1dXxRoaguqg@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)

> I am just noticing that your RFC still is marked as Draft, both within
> the RFC text and within the overview at https://wiki.php.net/rfc. Don't
> forget to adjust the status to =E2=80=9CUnder Discussion=E2=80=9D for pro=
per visibility.
>
> Am 2025-10-29 23:23, schrieb Dmytro Kulyk:
> > 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.
>
> I am seeing that you adjusted the RFC to remove the support for applying
> `#[\NoSerialize]` to classes. Given that we determined that serializing
> classes should either throw or work (i.e. that serializing them to
> `null` is never right), I don't think that two separate attributes are
> necessary. While a combined attribute would behave somewhat differently
> for classes and properties, the name of `#[\NoSerialize]` and
> `#[\NotSerializable]` is very similar and thus confusing in itself. I
> would suggest to merge the RFCs of `#[\NoSerialize]` and
> `#[\NotSerializable]` into a single attribute, since in both cases you
> are indicating =E2=80=9CI don't want this serialized=E2=80=9D and I think=
 it is
> reasonable to expect from users to learn that there is some difference
> in behavior for properties compared to classes.
>

Thanks, that=E2=80=99s a fair point =E2=80=94 combining both proposals woul=
d
definitely simplify the user-facing story and avoid naming confusion.

If we go in that direction, I=E2=80=99d suggest keeping the name
#[NoSerialize], because it=E2=80=99s more general and clearly describes the
action rather than the failure mode.
#[NotSerializable] reads more like an error state, while
#[NoSerialize] works naturally for both contexts =E2=80=94 skipping propert=
ies
silently and preventing class serialization (by throwing).

This way, the attribute name remains short and declarative, while the
actual behavior (throwing vs skipping) can be determined by where it=E2=80=
=99s
applied =E2=80=94 on a class or on a property =E2=80=94 without introducing=
 another
attribute.

Best,
Dmytro