Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113726 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 18363 invoked from network); 23 Mar 2021 17:24:07 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 23 Mar 2021 17:24:07 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id A4D661804C0 for ; Tue, 23 Mar 2021 10:19:40 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,FREEMAIL_REPLY, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 23 Mar 2021 10:19:40 -0700 (PDT) Received: by mail-lf1-f44.google.com with SMTP id o10so27791415lfb.9 for ; Tue, 23 Mar 2021 10:19:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ljZPcOSpsyPsUrWyVn5KZxEwA4uB1FrXmddtzQ28nf0=; b=qdkVDVwY18/1obGbZa6bO6Wvo+npSrvCV65W2IdRj9PtfdZoLBDZ4na6Pnu6TSAKIo ncJFmskNd4xg2zNoCvkCc08eWZS/vTHcEvTIl2fLRawW+BQORF5wVcjAdG9AE/Ptw5QN 27KFd+toDIe4ZqhBK5DspirzeBmTr0XIsTSHamp10t5JJWjCfSWMqvngWE6+wxWqT1jA XSufBEiPuk50NhAG48FYrhRuHXWesPrQsUVvWhnx+ofF0meXB3jFufZ0x4gTtJk4WBlr 9V1VXjPeY0I7mvJSaMRP51KUfp0cYNWpad+qX4iBY/Z63D6IR2Ajlp7FRGinCTVf3Tdi mzvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ljZPcOSpsyPsUrWyVn5KZxEwA4uB1FrXmddtzQ28nf0=; b=nn9eyJZNU5TWz0mnXGemc1TMgPG8CDEOVExLJC0+T6M9JRr5mkyPa+JqualmR7ygMd HLjEyN25h372bx7Pstq38SjwvFm1EpbhF1GHud5ruzj45JZ8eGJQrF6KohznTn7DkLRJ yUjOl9SXkAoWZ7ToG+WmgGOPao6mgD6fA/DJkIathHx3t4Rq0jKnGRlc9AdPyR1hxT5A stdu1+3NvMSkpfrJhwXqDJi1Gl9LOpiIkGbpk08SnO5LVuiIPE2apc1cKkJVx0EVrkoG BNqOHzkmVODhmWfaxYvKa/QpA5NwQJYI035NTMI4zuUcR1BHGilPRUtfQWmbiFNMIlea XHmQ== X-Gm-Message-State: AOAM531Q0dmhA2deFFbKNLqsN/ZezzotHMS7pSUx4bFpj1Xb51qwM8Fg IgPk2dZHR+L2xbRIcWv4/blctDGUqMPbPcW0xM4= X-Google-Smtp-Source: ABdhPJwgbSzZqtcxTfTrXgfwMyt2fPbl4VsQCQza1/mhDM7PNSX1mk1bfu7n585mmEMP1NBRICEnsNqkjX4QYmRq0DM= X-Received: by 2002:ac2:520f:: with SMTP id a15mr2977943lfl.223.1616519978462; Tue, 23 Mar 2021 10:19:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 23 Mar 2021 18:19:22 +0100 Message-ID: To: Nicolas Grekas Cc: PHP internals , =?UTF-8?Q?Bj=C3=B6rn_Larsson?= Content-Type: multipart/alternative; boundary="00000000000016b11b05be3763b4" Subject: Re: [PHP-DEV] [RFC] Phasing out Serializable From: nikita.ppv@gmail.com (Nikita Popov) --00000000000016b11b05be3763b4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 23, 2021 at 5:01 PM Nicolas Grekas wrote: > Hello Nikita, > > > Picking up a loose thread: >> https://wiki.php.net/rfc/custom_object_serialization introduced a >> replacement for Serializable in PHP 7.4, so it's time to think about >> deprecating and removing the old mechanism: >> >> https://wiki.php.net/rfc/phase_out_serializable >> >> This RFC follows a rather conversative approach. In PHP 8.1 there will b= e >> a >> deprecation warning if Serializable is implemented without also >> implementing __serialize() and __unserialize(). In PHP 9.0, support for >> Serializable is dropped internally, and only the interface retained. In >> PHP >> 10.0 the interface is dropped as well. >> > > > Reading the comments in this thread, the three-step approach is surprisin= g > to some. > What about deprecating in 8.1 and removing in 9.0 instead? > The stub Serializable interface can be provided in userland via a > polyfill, if anyone really needs a smoother transition plan. > > I'd really like to see this deprecation in 8.1, to stop ppl from writing > new implementations of Serializable asap. > I've updated the RFC to follow this suggestion. Bj=C3=B6rn, please tell me whether this addresses your concerns. Regards, Nikita --00000000000016b11b05be3763b4--