Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122091
MIME-Version: 1.0
References: <CAGgaK7+w_zdp30Pi5nJ-y+GPEkfc2xHfFUW+DwdpNtY8iPjMHg@mail.gmail.com>
 <CAOWwgpkW65ngNVrtu3oZ3_yAw4W+Qe1DsQ9LN-pfet_Psdy==Q@mail.gmail.com> <CABdc3WrjXkZSwfi+6mxDizKURhy7w8VUXoiAXEEytnwpGCEaUg@mail.gmail.com>
In-Reply-To: <CABdc3WrjXkZSwfi+6mxDizKURhy7w8VUXoiAXEEytnwpGCEaUg@mail.gmail.com>
Date: Wed, 3 Jan 2024 10:09:04 +0100
Message-ID: <CAOWwgp=Eo+dJbXVzumOJkrAQE8dG+eVZahJbd4326J8Ut6YtEA@mail.gmail.com>
To: =?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?= <michal.brzuchalski@gmail.com>
Cc: Max Semenik <maxsem.wiki@gmail.com>, Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000030a5d9060e06f8d4"
Subject: Re: [PHP-DEV] [RFC][Discussion] NotSerializable attribute
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--00000000000030a5d9060e06f8d4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> Hi Nicolas,
>
> =C5=9Br., 3 sty 2024 o 08:12 Nicolas Grekas <nicolas.grekas+php@gmail.com=
>
> napisa=C5=82(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 i=
s
>> inherited by descendants"), this is very unlike any other attributes, an=
d
>> 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

--00000000000030a5d9060e06f8d4--