On Sat, Dec 9, 2023 at 7:18 PM Niels Dossche <dossche.ni...@gmail.com> wrote:
> If you instead put #[NotSerializable] on the parent class MyClass, then > the child class won't be serializable even if you implement the > serialization methods in the child. > Is this intentional? If yes, this should probably be clarified in the text. Elaborated about the inheritance in the RFC and added a test around it in the PR. On Sat, Dec 9, 2023 at 7:29 PM Larry Garfield <la...@garfieldtech.com> wrote: > My main concern is that, as noted, *most* classes probably aren't > realistically serializable. Basically any service class should never be > serialized, ever, and anything that depends on a service class should never > be serialized, ever. So for this attribute to have the desired effect, it > would need to be added to most classes in a codebase. Which seems... like > a lot of work. In an ideal world serializability would be opt-in, but we > do not live in that world. > Indeed, adding it to every service would be an annoying overkill, but I wanted to use it on classes that should *really* not be (de)serialized. On Sun, Dec 10, 2023 at 2:46 AM G. P. B. <george.bany...@gmail.com> wrote: > Moreover, having this as an attribute means, that even without adding a new > method to ReflectionClass, you could determine via Reflection if this class > is serializable or not. > Because currently, the only way to know if it is *actually* serializable is > to call serialize() on the object and see what happens. > I've amended the RFC with proposed ReflectionClass additions. -- Best regards, Max Semenik
