> > >>> ś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. >> > > But then what should implement the NotSerializable interface? > If you want to ignore a string-typed property there would be no option to > mark it with a NotSerializable interface > Consider "baz" property in this example: > > class Foo { > protected int $bar = 1; > #[NotSerializable] > protected string $baz = 2; > } >
The attribute is #[Attribute(Attribute::TARGET_CLASS] so I'm not sure why you consider this as it's not mentioned in the RFC (and I'm not sure it would make sense).