Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129314
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> <CAPqq82vPdraqE1DuJQ6w4pWpwr1koTHcj_o0pKV1dXxRoaguqg@mail.gmail.com>
 <3a20b5ef66fc23de6bad022685b41190@bastelstu.be> <CAPqq82vbQzUidGG1h=hLhz7fxRrdZFav1RDjBw83aA0vqmpgUw@mail.gmail.com>
 <4e3061bfaa5218309041460d31be2856@bastelstu.be> <CAPqq82v89W_fXuMDqAK_2wYEZW8cTi6t7npDFQdZ7f54bsLAig@mail.gmail.com>
In-Reply-To: <CAPqq82v89W_fXuMDqAK_2wYEZW8cTi6t7npDFQdZ7f54bsLAig@mail.gmail.com>
Date: Wed, 19 Nov 2025 21:45:43 +0100
Message-ID: <CAOWwgpmT7knLmCTK=L_W+nJ1W1xEHxHdKJVW8j44bt_EhXPicQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][Discussion] Add #[NoSerialize] attribute for
 excluding properties or classes from serialization
To: Dmytro Kulyk <lnkvisitor.ts@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000aa23150643f8aa8f"
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000aa23150643f8aa8f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Dmytro


=D0=BF=D1=82, 7 =D0=BB=D0=B8=D1=81=D1=82. 2025=E2=80=AF=D1=80. =D0=BE 12:57=
 Tim D=C3=BCsterhus <tim@bastelstu.be> =D0=BF=D0=B8=D1=88=D0=B5:
> >
> > Thank you. The updated RFC is looking good to me. I also appreciate tha=
t
> > you kept a changelog within the RFC.
> >
> > One thing you could mention and that should be done as part of the RFC
> > is migrating all existing classes with `@not-serializable` to make use
> > of the attribute instead. That's also what has been done when the
> > `#[\Deprecated]` attribute was introduced. Other than that, I don't hav=
e
> > any further comments.
> >
>
> Thank you for the review and the helpful suggestion.
>
> I agree that all internal classes currently annotated with
> @not-serializable should also receive the corresponding
> #[\NoSerialize] attribute as part of this RFC. This ensures that
> internal metadata, reflection, and userland tooling remain fully
> aligned, and that the behavior is consistently exposed at both the
> engine and stub levels.
>
> The RFC has been updated to explicitly state that these attributes
> will be added for all such internal classes.
>
> I also have one technical question regarding stub generation:
> When attributes are emitted into generated arginfo.h files, should the
> generator automatically include zend_attributes.h?
> This would avoid requiring extensions to include zend_attributes.h
> explicitly when they do not use attributes themselves but only include
> generated stubs that reference them. Before making any implementation
> adjustments, I=E2=80=99d appreciate confirmation that this approach is
> acceptable within the current stub-generation design.
>
> ```
> /* This is a generated file, edit the .stub.php file instead.
>  * Stub hash: 2fc12d1fde65efbec4305f4934a3f4b25282a552 */
>
> #include "zend_attributes.h"
> ...
>     zend_add_class_attribute(class_entry,
> ZSTR_KNOWN(ZEND_STR_NO_SERIALIZE), 0);
> ...
> ```


Thanks for the RFC.

I think it=E2=80=99s an easy sell, but not necessarily for the right reason=
s. Let
me explain.

First, on property-level usage:
The RFC states that the attribute covers a common use case: transient or
resource-based properties in frameworks and libraries. On which fact is
this based? I checked code bases I know well, Symfony in particular, and I
had a hard time finding any implementation of __serialize()/__sleep() that
the property-level attribute would replace (ignoring BC). Symfony usually
exhibits most common and uncommon patterns, so if this were widespread, I
would expect to see some. More generally, having objects that embed both
value-state and a PDO connection looks like a design smell: such objects
behave differently before and after serialization, which is inherently
brittle. Such cases exist in the wild, of course, but making them a
first-class, favored use case in the language seems questionable.

Second, on class-level not-serializability:
This is a very common need. We had a thread a year ago discussing a
#[NotSerializable] attribute with identical semantics (
https://externals.io/message/121969). My position was and still is:
attaching this semantics to classes fits an interface far better than an
attribute. Even if it=E2=80=99s a negative contract, it=E2=80=99s still a c=
ontract, and
contracts propagate naturally to child classes. Attributes don=E2=80=99t, a=
nd
making this one an exception raises the question: why break attribute rules
when PHP already has the right tool - interfaces - to express this? The
engine currently uses a flag internally, but it could just as well use an
interface, removing a special case and aligning internal and userland
behavior. This follows a long and good tradition of replacing ad-hoc engine
features with userland-visible constructs.

Finally, a practical concern:
I wrote and still maintain the symfony/var-exporter
<https://packagist.org/packages/symfony/var-exporter> component, which
implements PHP=E2=80=99s serialization semantics in userland but outputs ex=
ecutable
PHP code. It is used in performance-sensitive cache systems. With the
proposed attribute, we would need reflection-based checks on every property
during both serialization and unserialization. Even with caching, this
would noticeably hurt performance. This is another argument in favor of an
interface BTW: instanceof/is_subclass_of() checks are much cheaper than
reading attributes for userland (not even counting the proposed inheritance
rule).

Thanks for considering my feedback.
Best regards,

Nicolas

--000000000000aa23150643f8aa8f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div>Hi Dmytro=C2=A0</div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr"><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">=D0=BF=D1=82, 7 =D0=BB=D0=B8=D1=81=
=D1=82. 2025=E2=80=AF=D1=80. =D0=BE 12:57 Tim D=C3=BCsterhus &lt;<a href=3D=
"mailto:tim@bastelstu.be" target=3D"_blank">tim@bastelstu.be</a>&gt; =D0=BF=
=D0=B8=D1=88=D0=B5:<br>
&gt;<br>
&gt; Thank you. The updated RFC is looking good to me. I also appreciate th=
at<br>
&gt; you kept a changelog within the RFC.<br>
&gt;<br>
&gt; One thing you could mention and that should be done as part of the RFC=
<br>
&gt; is migrating all existing classes with `@not-serializable` to make use=
<br>
&gt; of the attribute instead. That&#39;s also what has been done when the<=
br>
&gt; `#[\Deprecated]` attribute was introduced. Other than that, I don&#39;=
t have<br>
&gt; any further comments.<br>
&gt;<br>
<br>
Thank you for the review and the helpful suggestion.<br>
<br>
I agree that all internal classes currently annotated with<br>
@not-serializable should also receive the corresponding<br>
#[\NoSerialize] attribute as part of this RFC. This ensures that<br>
internal metadata, reflection, and userland tooling remain fully<br>
aligned, and that the behavior is consistently exposed at both the<br>
engine and stub levels.<br>
<br>
The RFC has been updated to explicitly state that these attributes<br>
will be added for all such internal classes.<br>
<br>
I also have one technical question regarding stub generation:<br>
When attributes are emitted into generated arginfo.h files, should the<br>
generator automatically include zend_attributes.h?<br>
This would avoid requiring extensions to include zend_attributes.h<br>
explicitly when they do not use attributes themselves but only include<br>
generated stubs that reference them. Before making any implementation<br>
adjustments, I=E2=80=99d appreciate confirmation that this approach is<br>
acceptable within the current stub-generation design.<br>
<br>
```<br>
/* This is a generated file, edit the .stub.php file instead.<br>
=C2=A0* Stub hash: 2fc12d1fde65efbec4305f4934a3f4b25282a552 */<br>
<br>
#include &quot;zend_attributes.h&quot;<br>
...<br>
=C2=A0 =C2=A0 zend_add_class_attribute(class_entry, ZSTR_KNOWN(ZEND_STR_NO_=
SERIALIZE), 0);<br>
...<br>
```</blockquote><div><br></div><div>Thanks for the RFC.</div><div><br></div=
><div>I think it=E2=80=99s an easy sell, but not necessarily for the right =
reasons. Let me explain.<br><br></div><div>First, on property-level usage:<=
br>The RFC states that the attribute covers a common use case: transient or=
 resource-based properties in frameworks and libraries. On which fact is th=
is based? I checked code bases I know well, Symfony in particular, and I ha=
d a hard time finding any implementation of __serialize()/__sleep() that th=
e property-level attribute would replace (ignoring BC). Symfony usually exh=
ibits most common and uncommon patterns, so if this were widespread, I woul=
d expect to see some. More generally, having objects that embed both value-=
state and a PDO connection looks like a design smell: such objects behave d=
ifferently before and after serialization, which is inherently brittle. Suc=
h cases exist in the wild, of course, but making them a first-class, favore=
d use case in the language seems questionable.<br><br></div><div>Second, on=
 class-level not-serializability:<br>This is a very common need. We had a t=
hread a year ago discussing a #[NotSerializable] attribute with identical s=
emantics (<a href=3D"https://externals.io/message/121969">https://externals=
.io/message/121969</a>). My position was and still=C2=A0is: attaching this =
semantics to classes fits an interface far better than an attribute. Even i=
f it=E2=80=99s a negative contract, it=E2=80=99s still a contract, and cont=
racts propagate naturally to child classes. Attributes don=E2=80=99t, and m=
aking this one an exception raises the question: why break attribute rules =
when PHP already has the right tool - interfaces - to express this? The eng=
ine currently uses a flag internally, but it could just as well use an inte=
rface, removing a special case and aligning internal and userland behavior.=
 This follows a long and good tradition of replacing ad-hoc engine features=
 with userland-visible constructs.<br><br></div><div>Finally, a practical c=
oncern:<br>I wrote and still maintain the <a href=3D"https://packagist.org/=
packages/symfony/var-exporter">symfony/var-exporter</a> component, which im=
plements PHP=E2=80=99s serialization semantics in userland but outputs exec=
utable PHP code. It is used in performance-sensitive cache systems. With th=
e proposed attribute, we would need reflection-based checks on every proper=
ty during both serialization and unserialization. Even with caching, this w=
ould noticeably hurt performance. This is another argument in favor of an i=
nterface BTW: instanceof/is_subclass_of() checks are much cheaper than read=
ing attributes for userland (not even counting the proposed inheritance rul=
e).<br><br></div><div>Thanks for considering my feedback.</div><div>Best re=
gards,<br><br></div><div>Nicolas</div><div></div></div></div>
</div>

--000000000000aa23150643f8aa8f--