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
