Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128787
Precedence: list
MIME-Version: 1.0
References: <CAPqq82ufEhv-adt1aCytK7d357egm93U=KhSq0yK+BMg_PLOWw@mail.gmail.com>
In-Reply-To: <CAPqq82ufEhv-adt1aCytK7d357egm93U=KhSq0yK+BMg_PLOWw@mail.gmail.com>
Date: Mon, 6 Oct 2025 12:02:21 +0200
Message-ID: <CAPyj-LDMtZzMo3QCcZ+j7b_4yYMMbbkRR8YMP4DS3-w3nAu05g@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC Proposal] Add #[NoSerialize] attribute for
 excluding properties from serialization
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Dmytro

Thanks for your proposal. This seems like a reasonable use of attributes.

On Mon, Oct 6, 2025 at 12:16=E2=80=AFAM Dmytro Kulyk <lnkvisitor.ts@gmail.c=
om> wrote:
>
> This proposal introduces a new attribute, #[NoSerialize], that can be
> applied to class properties to explicitly exclude them from
> serialization when using PHP=E2=80=99s built-in serialization mechanisms.

A few things:

* How does this interact with inheritance, i.e. is this flag inherited
to overridden child properties? I would assume no, as with other
attributes. But it would be good to spell it out.
* There are other forms of serialization, most notably JSON and
var_export(). Are these affected in any way? Does it make sense to
have a universal solution?
* There may also be a benefit to marking classes as entirely not
serializable, which would throw when encountering the class during
[un]serialization. We have some of those internally. [^1]

Ilija

[^1]: https://github.com/search?q=3Drepo%3Aphp%2Fphp-src%20%40not-serializa=
ble&type=3Dcode