Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128998
Precedence: list
MIME-Version: 1.0
Date: Wed, 29 Oct 2025 16:34:53 +0100
To: Dmytro Kulyk <lnkvisitor.ts@gmail.com>
Cc: Ilija Tovilo <tovilo.ilija@gmail.com>, PHP internals
 <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC][Discussion] Add #[NoSerialize] attribute for
 excluding properties or classes from serialization
In-Reply-To: <CAPqq82sy1O9-J4yhvcPvsob3Rjdi1wFDW_t597850sBTbKc=sg@mail.gmail.com>
References: <CAPqq82sqFy1y77XLu8Kbncg18WNopeJdPrfB+JQ8FWNZ4XpTQg@mail.gmail.com>
 <CAPyj-LBG0nR75AUMXT0XCnpNnPP=T62NYvRQ34yeZpd+i=cTPw@mail.gmail.com>
 <CAPqq82sy1O9-J4yhvcPvsob3Rjdi1wFDW_t597850sBTbKc=sg@mail.gmail.com>
Message-ID: <4b6abc36d8ab6cd306e95141869db3b0@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

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()`.

>> > Class-level #[NoSerialize] is inherited by child classes unless explicitly 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’s currently no way to override or cancel this behavior in
> descendants; the attribute remains effective throughout the
> inheritance chain.

Indeed, however the “unless explicitly overridden” bit in the RFC text 
implies that this is possible.

> As an alternative, #[NotSerializable] could be extended to
> #[NotSerializable(bool $soft = false)], which would provide the same
> behavior while keeping it in a separate, more consistent attribute —
> 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.

> Initially, the idea was to make all of these cases emit warnings, but
> I didn’t figure out how to implement that consistently within the
> attribute validators.
> At this point, I don’t see any practical reason to allow the attribute
> 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
Tim Düsterhus