> 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 “Under Discussion” for proper 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 “I don't want this serialized” 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’s a fair point — combining both proposals would definitely simplify the user-facing story and avoid naming confusion. If we go in that direction, I’d suggest keeping the name #[NoSerialize], because it’s 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 — skipping properties 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’s applied — on a class or on a property — without introducing another attribute. Best, Dmytro
