śr., 3 sty 2024 o 11:10 Nicolas Grekas <nicolas.grekas+...@gmail.com> napisał(a):
> >>>> ś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). > Apologies, apparently I didn't read. Cheers
