Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:128668 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 E247C1A00BC for ; Wed, 10 Sep 2025 16:17:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1757520968; bh=MrFPu+NZ7hm1xS83S12XlgMwIw4ts9G9WMXRhEJZeaQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=SGhJC0xad5M09r2TrUhjIczvOw3whJ48SWJbAiMlWD8roVYpZzDOiP1NOHPiLiH5h EMnBHVtMzewcsrRSdbatn53Gk0iScefJGBfw+UF16lCr6J1xxBSWw3tSqGC9SUYOnH 7OrDjB9/XOB1cCw0fPoBNpxCzMOExAg7QZSG2KX8V9kG8svT3Emt7gA9rdk6wKfS4r e2mNoq1FCbqzVxqoLZJaXodzNiV6A0RfGF18nSK+XtbIBA1okUR6emsqA/wNr6tM6Q 3RrSzIUUD7EC1lixxGhxfrG0vOGtNCezL0HgMhcLKqJsdNX3BPb9rUxp+sv3abOoTT MKjsiStT6IDow== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 89E771801DB for ; Wed, 10 Sep 2025 16:16:07 +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.7 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) (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 ; Wed, 10 Sep 2025 16:16:07 +0000 (UTC) Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-4b5fbd77f40so62086451cf.2 for ; Wed, 10 Sep 2025 09:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757521053; x=1758125853; 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=YnW0fcmqXXddYFxyWZC4PHu5YtJ1Q1knLCAmovn5nAA=; b=P1EBw3V7zMXCOjpd518Tgi3l0JMI3tBOOx/yglFiG254ab/6JGIa8N4OgF+ZUB9hHl dkGLjwfCr4cxc4hJXYBp/RZC3cl0qzkWfJAGPHg8xgF48yOMFTsAUN6GKb3SP6oZ/AS5 xrNgH5FgyVg/MLLHlwPG6tzInPEvQWxZA1j+hK7oE/bsgD/J/RiGXbE4Lvo3jOJTIwkl IuuOpU2m1MATiyisW85ssjUex74i4SpKm8gDl+eod/5IOarX6l3zQJXd/J/yw6zd/A0V s3nFA4SKJvwGJDBV8TFOwQMkQj0OgS1i8LXs0cWMVZmq7uTYGBs3wHYxiPEqukv4GuGm OdPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757521053; x=1758125853; 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=YnW0fcmqXXddYFxyWZC4PHu5YtJ1Q1knLCAmovn5nAA=; b=gTWgdgzjrJXpp5N23gXvx8TT47oVPU3AAnf1FGIgOw/+CWoWXglpjDAt97ToRcGpPX 1YB6Z5xPbRXeH8ByaNH6j6zXkVsctPcvXJW/45dB7ifClpMuAmqjG9nLzrq6R1E4JX/8 3+ilH78gMDtdXzJ0B4lQTyVoJ0Z4EGvNAz5TCRQ4vRGxwxIbL37MLGiO/GPsqC9y/YCH gBEz5CloKR+Yga+5S2eohn+4sx1H90BHik5u4ro5iQ4MFk7fa8YPap/+ZTNk3kiO1ije iZz4Pbz/eIOviPbr4LbmmIi1r6OcpifjWihHoK2h/bHMLoYndWy06CkpMW8n1f6ubinO 7/ww== X-Gm-Message-State: AOJu0YxvkFMGjBnKPXfdF2Lfgo+o6Vk0qOXhdOVUouKMKc8bx2A35Wz+ quk2XVO+L7jTLl8TUhdsZy/wgcltoYW9TwKbrux1T4IJTKv08EshvSosUhgYHUNoc5/CeAuCEX4 q2yMTtr+iSVmFkXd0TIUYYRQeG+dSYmdGijI/yG8= X-Gm-Gg: ASbGnctXeYdJUnWKLUTrvPGWr7R75imxVYD/7bfe7y4IIKm5e8py2pLuZvwqbLQhRwa zz0M7bzVW2tT6RB8MrV58+c9OCgrDBcySCWCIYsq/JuVwRQBhjYdnxD2a1T2B5KEzfc4PH0Lc1J y+th6wk3sLkv903jDMz6Raf6/c9wAwCAvyGEmiBIiE+v2zQk0AkheFSHJmGJ+m6z6dCFrnKAKfK ScJnIRNpA3KHQ6Gv2A= X-Google-Smtp-Source: AGHT+IGqSxhppLzOBtVHoFJeTYrquOYmTfVe64hfJrDjrMqCkuGdIz/8Gx+SIUDr4pMpSqOA56Dp225QmXyIzwUcZaM= X-Received: by 2002:a05:622a:1647:b0:4b4:96a8:f79c with SMTP id d75a77b69052e-4b5f84ac9f9mr183590071cf.79.1757521053076; Wed, 10 Sep 2025 09:17:33 -0700 (PDT) Precedence: list list-help: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 10 Sep 2025 18:17:20 +0200 X-Gm-Features: Ac12FXzi-mWqfdlaPeq3zMGMsIQDb3UyTXo6ZvRhKnJKKjVwNPrH8jG-Tiw2CCE Message-ID: Subject: Re: [PHP-DEV] [RFC] Soft-Deprecate __sleep() and __wakeup() To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= Cc: PHP Internals List Content-Type: multipart/alternative; boundary="0000000000000dd6a9063e74c222" From: nicolas.grekas+php@gmail.com (Nicolas Grekas) --0000000000000dd6a9063e74c222 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tim > Hello internals, > > > > Following the discussion that started at > > https://externals.io/message/128226#128456 I wrote this RFC to > > formalize > > our consensus on the topic. > > > > TL;DR, this is about converting the deprecation of __sleep and __wakeup > > to > > a documentation-based soft deprecation: > > https://wiki.php.net/rfc/soft-deprecate-sleep-wakeup > > Thank you for the RFC. I have some comments: > > 1. > > I disagree with the phrasing that the RFC passed with a =E2=80=9Cnarrow m= argin=E2=80=9D. > While it is technically true, that this is the narrowest margin for > accepting an RFC, the necessary margins are already biased in favor of > not accepting an RFC. That the RFC was accepted means that a significant > majority of voters were in favor of the deprecation. I did not vote, > since I did not have sufficient time to form an opinion on the RFC, but > given the knowledge I've gained as part of the discussion I would now > vote in favor of the RFC. > Jakub addressed that in a sub-thread. 2. > > The examples are biased. As an example, the initial =E2=80=9CUser=E2=80= =9D example has a > serialization hook that is completely useless. The other examples try to > replicate `__sleep()`'s broken behavior exactly, which seems to be a > relevant requirement in the real world for only a minority of users. > The quantitative argument is not the only measure of the impact. The RFC explains why - qualitatively - the RFC will have a significant impact. For the quantitative part, we can talk forever before agreeing. > 3. > > Similarly, I believe that the RFC *overstates* the cost of the > deprecation. From my experience a majority of serialization hooks will > just unconditionally throw an exception to prevent serialization. The > truth is probably somewhere in the middle. > I'm not sure why you talk about throwing hooks. Those are not concerned so that's orthogonal to the points made. From the small but not negligible share of the community I'm working with, having both Doctrine and Symfony impacted means the impact will be significant. Add that to the fact the "fix" is risky (what the RFC explains), and this will be a costly RFC for sure. Note that as Jakub figured out in the latest example he added, not only library-level codebases will need complex fixes: e.g. app-side user objects that use __sleep/wakeup and that are put into a session storage will need something as complex to address the deprecation without disrupting their connected users. > 4. > > The RFC correctly acknowleges that `__sleep()` is broken with regard to > private properties, but at the same time claims that the deprecation > does not fix a =E2=80=9Ccorrectness problem=E2=80=9D, which is a contradi= ction. > I clarified this aspect in the RFC this way ("No technical urgency" section): > Some consider that __sleep() is broken because it is incompatible with nested private properties. Yet, this is more of a limitation rather than something being broken: many use cases don't need access to private properties and are just fine with the method. When one needs to overcome this limitation, one can migrate to __serialize, on an opt-in basis. > 5. > > The serialization mechanism is also a security sensitive part of the > language, the fewer moving parts there are, the better. Security is part > of the motivation for me. > Jakub addressed that in a sub-thread also. > ---------------------- > > That all said, as I've said before: I see that replacing __wakeup() by > __unserialize() is non-trivial and I would be okay with deferring that > one until we have some helper (e.g. `**s**et_mangled_object_vars`). But > __sleep() can just go away. > We've added a note in the "Future scope" section, phrased like this: > Consider dealing with __wakeup / __sleep separately as the impact might be specific to each one Cheers, Nicolas --0000000000000dd6a9063e74c222 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tim


> Hello internals,
>
> Following the discussion that started at
> https://externals.io/message/128226#128456 I wrot= e this RFC to
> formalize
> our consensus on the topic.
>
> TL;DR, this is about converting the deprecation of __sleep and __wakeu= p
> to
> a documentation-based soft deprecation:
> https://wiki.php.net/rfc/soft-deprecate-s= leep-wakeup

Thank you for the RFC. I have some comments:

1.

I disagree with the phrasing that the RFC passed with a =E2=80=9Cnarrow mar= gin=E2=80=9D.
While it is technically true, that this is the narrowest margin for
accepting an RFC, the necessary margins are already biased in favor of
not accepting an RFC. That the RFC was accepted means that a significant majority of voters were in favor of the deprecation. I did not vote,
since I did not have sufficient time to form an opinion on the RFC, but given the knowledge I've gained as part of the discussion I would now <= br> vote in favor of the RFC.

Jakub address= ed that in a sub-thread.

2.

The examples are biased. As an example, the initial =E2=80=9CUser=E2=80=9D = example has a
serialization hook that is completely useless. The other examples try to replicate `__sleep()`'s broken behavior exactly, which seems to be a relevant requirement in the real world for only a minority of users.

The quantitative argument is not the only mea= sure of the impact.
The RFC explains why - qualitatively - the RF= C will have a significant impact.
For the quantitative part, we c= an talk forever before agreeing.
=C2=A0
3.

Similarly, I believe that the RFC *overstates* the cost of the
deprecation. From my experience a majority of serialization hooks will
just unconditionally throw an exception to prevent serialization. The
truth is probably somewhere in the middle.

<= div>
I'm not sure why you talk about throwing hooks. Those are= not concerned so that's orthogonal=C2=A0to the points made.
From = the small but not negligible share of the community I'm working with, h= aving both Doctrine and Symfony impacted means the impact will be significa= nt.
Add that to the fact the "fix" is risky (what the R= FC explains), and this will be a costly RFC for sure.
Note that a= s Jakub figured out in the latest example he added, not only library-level = codebases will need complex fixes: e.g. app-side user objects that use=C2= =A0__sleep/wakeup and that are put into a session storage will need somethi= ng as complex to address the deprecation without disrupting their connected= =C2=A0users.
=C2=A0
4.

The RFC correctly acknowleges that `__sleep()` is broken with regard to private properties, but at the same time claims that the deprecation
does not fix a =E2=80=9Ccorrectness problem=E2=80=9D, which is a contradict= ion.

I clarified=C2=A0this aspect in th= e RFC this way ("No technical urgency" section):

>=C2=A0 Some consider that __sleep() is broken because it is in= compatible with nested private properties. Yet, this is more of a limitatio= n rather than something being broken: many use cases don't need access = to private properties and are just fine with the method. When one needs to = overcome this limitation, one can migrate to __serialize, on an opt-in basi= s.
=C2=A0
5.

The serialization mechanism is also a security sensitive part of the
language, the fewer moving parts there are, the better. Security is part of the motivation for me.

Jakub ad= dressed that in a sub-thread also.
=C2=A0
----------------------

That all said, as I've said before: I see that replacing __wakeup() by =
__unserialize() is non-trivial and I would be okay with deferring that
one until we have some helper (e.g. `**s**et_mangled_object_vars`). But __sleep() can just go away.

We've a= dded a note in the "Future scope" section, phrased like this:

>=C2=A0Consider dealing with __wakeup / __sleep se= parately as the impact might be specific to each one

Cheers,
Nicolas
--0000000000000dd6a9063e74c222--