The implementation is simple and straight to the point, and uses machinery that has been added to the engine to deal more consistently with internal classes.
In an ideal world (IMHO) serialization would be opt-in and __serialize() would be used to enable and describe the serialization format. However, this is not the case, and IMHO implementing __serialize() should only be done to change the *default* serialization format *not* to disable it. Exposing this to userland makes sense, as this would prevented the mess that was the Serializable interface that people used to disable serialization which was less then ideal. 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. On Sat, 9 Dec 2023 at 17:16, Rowan Tommins <rowan.coll...@gmail.com> wrote: > On 9 December 2023 12:30:29 GMT, Max Semenik <maxsem.w...@gmail.com> > wrote: > >Hi, I'd like to propose a new attribute, #[NotSerializable]. This > >functionality is already available for internal classes - userspace should > >benefit from it, too. > > If this ends up approximately the same as implementing serialisation as an > exception, it feels quite a thin feature. If you put __sleep and __wakeup > as shown into a trait, it's already as short and explicit as "use > NotSerializable;" > If the alternative solution is a trait, then it is, IMHO, a bad alternative solution. What would make it more compelling is if the engine itself could do more > with the attribute. For instance, a direct isSerializable() on > ReflectionClass that covered both internal and attribute-marked classes. > I do agree, adding a isSerializable() function to ReflectionClass is a good idea. Best regards, Gina P. Banyard
