> Hi Nicolas, > > śr., 3 sty 2024 o 08:12 Nicolas Grekas <nicolas.grekas+...@gmail.com> > napisał(a): > >> Hi Max, >> >> Hi, I'd like to propose a new attribute, #[NotSerializable]. This >> > functionality is already available for internal classes - userspace >> should >> > benefit from it, too. >> > >> > The RFC: https://wiki.php.net/rfc/not_serializable >> > Proposed implementation: https://github.com/php/php-src/pull/12788 >> > >> > Please let me know what you think. >> > >> >> Regarding the inheritance-related behavior ("The non-serializable flag is >> inherited by descendants"), this is very unlike any other attributes, and >> this actively prevents writing a child class that'd make a parent >> serializable if it wants to. >> >> To me, if this is really the behavior we want, then the attribute should >> be >> replaced by a maker interface. >> Then, a simple "instanceof NotSerializable" would be enough instead of >> adding yet another method to ReflectionClass. >> > > This should be possible without ReflectionClass, see > https://3v4l.org/N3fmO >
Sure. My main point is : why use an attribute? this should be an interface to me. All semantics match an interface. > From the serialization libraries you can find similar attributes > Those a very different, because they tackle the problem from the *external* angle: the attributes there describe how a system *external* to the class itself should best serialize an object. There, attributes make sense, because they enrich the description of the class without forcibly telling what to do with the object But in the RFC, we're talking about the object deciding itself how it should be (not) serialized. This is enforced and thus belongs to the typesystem - not to an attribute. IMHO Cheers, Nicolas
