Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122089
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\))
In-Reply-To: <CAOWwgpkW65ngNVrtu3oZ3_yAw4W+Qe1DsQ9LN-pfet_Psdy==Q@mail.gmail.com>
Date: Wed, 3 Jan 2024 00:34:43 -0800
Cc: Max Semenik <maxsem.wiki@gmail.com>,
 Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <369B4CA4-3468-43C4-93FA-4944BAFC0973@woofle.net>
References: <CAGgaK7+w_zdp30Pi5nJ-y+GPEkfc2xHfFUW+DwdpNtY8iPjMHg@mail.gmail.com>
 <CAOWwgpkW65ngNVrtu3oZ3_yAw4W+Qe1DsQ9LN-pfet_Psdy==Q@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
Subject: Re: [PHP-DEV] [RFC][Discussion] NotSerializable attribute
From: dusk@woofle.net (Dusk)

On Jan 2, 2024, at 23:11, Nicolas Grekas <nicolas.grekas+php@gmail.com> =
wrote:
> 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.

That seems appropriate. Consider a class which has set itself as =
#[NotSerializable] because it contains something which mustn't be =
serialized (like a secret or an identifier returned by an FFI library), =
or because the lifecycle of objects of that class needs to be tightly =
controlled (like a singleton or a scope guard). It shouldn't be possible =
to make any of these serializable by creating a subclass.=