Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120652 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 38526 invoked from network); 21 Jun 2023 08:43:52 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 21 Jun 2023 08:43:52 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 7B4531804D0 for ; Wed, 21 Jun 2023 01:43:51 -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.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-oa1-f54.google.com (mail-oa1-f54.google.com [209.85.160.54]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 21 Jun 2023 01:43:50 -0700 (PDT) Received: by mail-oa1-f54.google.com with SMTP id 586e51a60fabf-19fa4346498so4940733fac.1 for ; Wed, 21 Jun 2023 01:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687337030; x=1689929030; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=cdSk+R8scsMS68d8nP0Zu3tZfRCLNsjsjALt/jBZWgE=; b=RpoF9Yact5tIos6+54V7cj0GqydXBWQmqCVQjypAvOFZDAMKMPkE2kh8g72jCuEpP6 XZ3NpJuUx0lAkpH0UsP8ZwmOllmCmklzeLMTfZVzSHGXPGumPy75GemC+8fBqV4rbku3 llk6weoaP4BNbCxMuS5RpF2a0SfGKeGWv67JkxUwxVL78NCD+/RdL7qX7uEkXLQOf0mY pDOjX0JeZxLd+Owt7ykBBrciVHjW++/Bp6lI2DUJaM8daPWSF4HjDT2iEbGh//wNxRzi wmkxZCVUO4vXgP7w9kGF1Sn3vrF2a58ynOhwESSXlk9+ik2yjdPFlWjeNB/ngZ/IMVxL oXzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687337030; x=1689929030; 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=cdSk+R8scsMS68d8nP0Zu3tZfRCLNsjsjALt/jBZWgE=; b=AgCeaxgz5nK0no3J8BVgzQ1fdEcbpkYMI+Ak+mI39TwYnbPTS3d9LedqEi6p9ZdAY0 JUE7eZBZr/8lr2mLT9WnfUAaKxL1gv/TilU1r44xsfU6n+OtypgHm9srzF3stsWF6BkK 91+oAK9Kl0Ooj0MgxrCml4LBRQk870vLqfWIohE1roC7EWeauvBzHafkWmGIbPuapgi3 RBk0pfuxQuijl09Nty99mI7+Rh61PKxMxupO7nAwtOlRoOgMO/GQIkzUcHRvH45qS2zj NmK8LCcuPTbeS060srOWlQ2GMCkXouHgXktl9QB2s5i4UEqbI5NxFrsAS0q3wDK035xP +3FA== X-Gm-Message-State: AC+VfDzyQyQch6DxrmSqttTAbF721XyqfiLMZZWhe7wy7PkHRiZ9pkAz pJnNn58/o05sg1nmRS1TS23hSmBpLGHl0RJJl8MwaSX56g0UMw== X-Google-Smtp-Source: ACHHUZ7T9ky9IDiqzJHkeNhs79AwC8Qj+sggDnQL+Ta933+XdfnsBkut/9lXXFHGT8IwfmRyW8fc8OSGPay5CKqjH5U= X-Received: by 2002:a05:6870:284:b0:1a9:cb0d:a253 with SMTP id q4-20020a056870028400b001a9cb0da253mr10239808oaf.27.1687337030227; Wed, 21 Jun 2023 01:43:50 -0700 (PDT) MIME-Version: 1.0 References: <108411AD-DBC4-4436-8190-7569B7A0805F@gmail.com> In-Reply-To: Date: Wed, 21 Jun 2023 10:43:38 +0200 Message-ID: To: Bruce Weirdan Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary="0000000000004d9b9e05fe9fc4ad" Subject: Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=) --0000000000004d9b9e05fe9fc4ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bruce, For those who use callbacks now, how is this in any way better? They will > eventually end up using an OOP approach anyway (as that's the strategic > goal). > Migrating from `session_set_handler_callbacks()` would still be > (potentially) > non-trivial. And what's the point migrating *to* > `session_set_handler_callbacks()` > if we already know it will be deprecated and removed soon enough? The reason why I think it's a good approach to have an intermediate state is to give these people the possibility to defer the actual migration until the very end. So they can choose what to do when the 6+ parameter version of session_set_save_handler() becomes deprecated: they can either go straight to session_set_handler() *if they are ready* or they can also choose gaining time with a very straightforward change and us= e session_set_handler_callbacks() for at least a couple of years more. The important thing is that people are not yet forced to make a bigger effort, unless they are already ready for that. Regards, M=C3=A1t=C3=A9 --0000000000004d9b9e05fe9fc4ad--