Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:128852 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id 84FFC1A00BC for ; Thu, 16 Oct 2025 07:40:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1760600448; bh=Uz7rxoMI6qBupnAWL0iGVGG1WchWb1lHqhxmczyrX8U=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=H+d2MIhZrAhEIVBhcIjBREjVfcilnCZL7nD2PEQc0QbR1X0OH/eSjy7Q01Jfir3VU NuNPfc9+p9KyG3Z1HDt614RQyk38NDU9YxEAc/AVWea3cEUkuwk+puuRNbv0e48wIQ +9Q9W1NwqX8bPF5t54QpxiIAj0eulo7O8rkarLdJBPFU1iW2p3Xz9egL0ZY8yOWymR 4TU6Go8Fnt+cWycltzBXj9ucWOYh2zpmEeNz3g6DRqC6vJFIjJcICuZlETJfKhn+Om nxCztF8cbTKd5W/6mAoRXUBFEhtjKAZP0n/+iQNuijSe2SQNGwc227TUB1eHOd2IZA WQodoPTaGlPDw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id DD63C1804FF for ; Thu, 16 Oct 2025 07:40:44 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_40,DKIM_SIGNED, DKIM_VALID,DMARC_MISSING,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 16 Oct 2025 07:40:32 +0000 (UTC) Received: by mail-lf1-f53.google.com with SMTP id 2adb3069b0e04-57bb7ee3142so565595e87.0 for ; Thu, 16 Oct 2025 00:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=beberlei-de.20230601.gappssmtp.com; s=20230601; t=1760600426; x=1761205226; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=R3+w74rGNct0sw5bGawNSh8UQTWer5IKDTZdwMbtMkQ=; b=IsE8XXLJv+t9O1khBBZF/INgdCXiQ3Fb+5OHxX7iKSUSs0nUV8vgsMrX3/ECyVeTH5 LuuEc/ej1Rs5akBFIMMjTwIpInh4UVEAbBZiYpA7FFr2xZClpvcjoTHFxzgEZV0RA55g cjt412zZNm8nsfqtWnEcZEtgqfeKVgJP7OdtAHdGODv7Q5o1qaXSp9UrrMaX4gBCLCNr obpauZx8cDrc/hIOwLho2mlMDoUF3dGo6PMvBhx/6lJ2chaFD7MfLqP9EJrZ0a6xxQYv OyuXvOzlGbg409XaNBovOOaGGZr+TpEWwZFwIUV5xHObvPBZ70Sfurqi3+dR/ZvGc6uA m/OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760600426; x=1761205226; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=R3+w74rGNct0sw5bGawNSh8UQTWer5IKDTZdwMbtMkQ=; b=nbwS0qEeI+zyzSvUOaQ8uGbN3fa6tY5Y8qZzc2HewRNYT3ZYY3kfONubsuKq6Fg2ZL 6hr670WgvtezyVqpCzlAcozerzoi6Hik5kRJOOfEfHo0E7pOqZcgTmKYUaPaUwl2Uhm9 JI3b90emV6LBtKT07t/VeYBQX2/wdTyghN1IieaaBD6Di+wH0eVWn8cO1jqu4YDyx0Zp 2lH3jG6ySJ2dCdAwyIM38MDRUq1jlNqQI4xVj/Bb1MOGXRYrJ7rYG/HCXtqN3aaDmuu4 yc75QLxTD2aZ2wGQXZCicD+AfaVNotuS1Tk7ZaAVgQnxhK0dgZrSdrGWSafha9UY3CwU S4oQ== X-Gm-Message-State: AOJu0Yy2cFaO0TZF97Vga6ZQkneZ4CqTuTBqE1U44S/5oTku9wVeGis3 UIkiKuZ7/nGjIsZ1q5TjWqbAKSH4PwBDpi3XnHlK9Ww1cM/CJogZ1+jo0h5EU2CAZc27kiygFaw 98s/2fcw0ITS1j4VASPcM0sk4AWnl/tVNVbQ9YvPztdfEV9TyavTKANM= X-Gm-Gg: ASbGncsSR+2j7teagy6f9Mc4f9dF6vg9bW7wOTWp8lYIr1BfgVFljCi9ZoAkLGPS3Cg QQBWvfV5urbktj9TcPx0sCcHztQkZtBUn+vGBVIjC+YbmqoLt9rxPnAznel2MrD4VidhpAyRxk1 CPGvAwrDl8NT1F26sOKizR2wHWFhh16wupaSLugZuu2W5Iprr1TRMeUrmfGSuCKnaHj/TxJw/5B N/TlxoVzmp20y38LxCvl28pzdQmmvjt1yP4Pllq7jefPPrZeRnzi2/35+JBhAtVcszsG5XrIAaP rkhafU++inX24cKzkg== X-Google-Smtp-Source: AGHT+IHqk4pnc1ZjiF0oThqog6cVuRyIiqsdaes/uTP6W+7vmLpCV6wJX3gHGiDh2pmYzlpxnrFcSjToo3Fe+tNDevA= X-Received: by 2002:a05:651c:1588:b0:36c:47c8:b618 with SMTP id 38308e7fff4ca-37609da0dffmr85620381fa.18.1760600425643; Thu, 16 Oct 2025 00:40:25 -0700 (PDT) Received: from 1064022179695 named unknown by gmailapi.google.com with HTTPREST; Thu, 16 Oct 2025 00:40:24 -0700 Received: from 1064022179695 named unknown by gmailapi.google.com with HTTPREST; Thu, 16 Oct 2025 00:40:21 -0700 Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 (Mimestream 1.8.3) References: <2d65c5b9-0fb6-41eb-a928-69d742b2ec82@app.fastmail.com> In-Reply-To: <2d65c5b9-0fb6-41eb-a928-69d742b2ec82@app.fastmail.com> Date: Thu, 16 Oct 2025 00:40:24 -0700 X-Gm-Features: AS18NWAY7nKoNNy-P4smxQiRRusF2E3Irt_NjnyyL7xACatRQM2mA3KVmFkryRw Message-ID: Subject: Re: [PHP-DEV] [RFC][Discussion] NotSerializable attribute To: Larry Garfield Cc: php internals Content-Type: multipart/alternative; boundary="000000000000f64d96064141ba16" From: kontakt@beberlei.de (=?UTF-8?Q?Benjamin_Au=C3=9Fenhofer?=) --000000000000f64d96064141ba16 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Am 03.01.2024, 20:21:22 schrieb Larry Garfield : > On Wed, Jan 3, 2024, at 7:11 AM, Nicolas Grekas wrote: > > 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. > > > Cheers, > > Nicolas > > > I think I'm inclined to agree with Nicolas. If the intent here is to > impact mainly serialize()/unserialize(), then a marker interface seems li= ke > it has the desired logic "built in" more than an attribute does. It woul= d > only work at the object level, but that seems correct in this case. For > excluding individual properties, __serialize()/__unserialize() already > support that use case. That's one of the main uses for them. > > User-space serializers (Crell/Serde, JMS, Symfony, etc.) could easily be > modified to honor the interface as well for external serialization. > I have to disagree, and would favor this more when it becomes an attribute vs a marker interface. Attributes are precisely there to avoid marker interfaces. And there is no precedent in PHP of something similar that suggests we should use a marker interface. The impact on inheritance is not related to this being an attribute, it is already the behavior of the engine with the ZEND_ACC_NOT_SERIALIZABLE flag, you can=E2=80=99t extend PDO and serialize its decendent for example. Ant t= here is no way to overwrite that in the child class either. Yes, with an attribute it requires considerably more code to check for serializability in a user-space code, than to check for a Marker interface. But thats not a good enough reason to introduce a new pattern into the language. The same argument could be made to anything related attributes why we added that to reflection and not added =E2=80=9Eeasier functions=E2= =80=9C. > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > --000000000000f64d96064141ba16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Am 03.01.2024, 20:21:22 schrieb L= arry Garfield <larry@garfieldt= ech.com>:
=20
On Wed, Jan 3, 2024, at 7:11 AM, Nicolas Grekas wrote:
Hi Max,

Hi, I'd like to propose a new attribut= e, #[NotSerializable]. This
> = functionality is already available for internal classes - userspace should<= br>
> benefit from it, too.
>
> The RFC: https://wiki.php.net/rfc/not_serializable
> Proposed implementation: https://github.com/php/php-src/pull/12788
<= /blockquote>
>
> 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 attribu= tes, and
this actively prevents = writing a child class that'd make a parent
serializable if it wants to.

To me, if this is re= ally the behavior we want, then the attribute should be
replaced by a maker interface.
Then, a simple "instanceof NotSerializable"= ; would be enough instead of
add= ing yet another method to ReflectionClass.

Cheers,
Nicolas

I think I'm i= nclined to agree with Nicolas.=C2=A0 If the intent here is to impact mainly= serialize()/unserialize(), then a marker interface seems like it has the d= esired logic "built in" more than an attribute does.=C2=A0 It wou= ld only work at the object level, but that seems correct in this case.=C2= =A0 For excluding individual properties, __serialize()/__unserialize() alre= ady support that use case.=C2=A0 That's one of the main uses for them.<= br>
User-space serializers (Crell/Serde, JMS, Symfony, etc.) could easil= y be modified to honor the interface as well for external serialization.

I have to disagree, and would favor this more = when it becomes an attribute vs a marker interface.

Attributes are pr= ecisely there to avoid marker interfaces. And there is no precedent in PHP = of something similar that suggests we should use a marker interface.
<= div class=3D"gmail_quote" dir=3D"ltr">
The impact on inheritance is not related to this being an attri= bute, it is already the behavior of the engine with the ZEND_ACC_NOT_SERIAL= IZABLE flag, you can=E2=80=99t extend PDO and serialize its decendent for e= xample. Ant there is no way to overwrite that in the child class either.=C2= =A0

Yes, with an attribute it requires considerably more = code to check for serializability in a user-space code, than to check for a= Marker interface. But thats not a good enough reason to introduce a new pa= ttern into the language. The same argument could be made to anything relate= d attributes why we added that to reflection and not added =E2=80=9Eeasier = functions=E2=80=9C.


--Larry Garfield

--
PHP Internal= s - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
--000000000000f64d96064141ba16--