Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120649
MIME-Version: 1.0
References: <CAH5C8xXtCVHaxwzmAW_eBxp_D6p7kww9svND=3AEeC9X6--YXg@mail.gmail.com>
 <eaaa805e-86b2-ce8c-5a24-c301260d16ac@php.net> <CAH5C8xUrNktmO=t1-357uE0UAZHe0O2zYdAxwE3a0Oo-MK7R=Q@mail.gmail.com>
 <CAH5C8xXjMP+D5szYCZdWqe2pdQTPOMbuFEtJGZeoeTYBcJFOrw@mail.gmail.com>
 <108411AD-DBC4-4436-8190-7569B7A0805F@gmail.com> <CAH5C8xXY3-YjbO6Dq20hRmLUETA3FEpx+rk4+9J3LwO10R6ojA@mail.gmail.com>
 <CAH5C8xW2eXsC5tY5zkZo9TE2QsvvDjdaLzjjZiGKHSJZq6qFJw@mail.gmail.com>
 <D25C28C4-271D-456D-99A5-DA66971FCD00@gmail.com> <CAH5C8xV=NJKV7KdA3v2M_6ZNPMAF6i38aPXqiCkoTYzBSRzY0g@mail.gmail.com>
 <CALKiJKrPP_DLrsrm_5gBOfZ7Exje+RLJdJrRHx4wu894dvr2Hg@mail.gmail.com>
 <CAH5C8xXc8ty7tNgk60JPXq3UZwUigPsPFd8XV=CzxBGT5xXvZw@mail.gmail.com>
 <CAOWwgpmHh9tcuxrNr2pUJy74gMgouVz=B5WkTtMO1a-Qe7mBmA@mail.gmail.com>
 <d63738cf-2711-8d2a-0935-7ecdabc5c9a6@gmail.com> <CAOWwgpkRdKwFOWwnLciPQRxjimaGtr-ATFFCpFgB1JjH18AyQA@mail.gmail.com>
 <cce7b9ee-c418-f19a-81eb-d2a7a5399949@gmail.com> <CAOWwgp=uRyn5kmv+oG=2ikf5bzwgBOR6RqSedt7nkMmeg+3aNw@mail.gmail.com>
 <CALKiJKrOU+PDa1+DUUxJ9yqMvnHn5AsDtZ5cgV3cvVGtzf5Qhg@mail.gmail.com>
In-Reply-To: <CALKiJKrOU+PDa1+DUUxJ9yqMvnHn5AsDtZ5cgV3cvVGtzf5Qhg@mail.gmail.com>
Date: Wed, 21 Jun 2023 00:53:29 +0200
Message-ID: <CAH5C8xU=wae81qcCPuvEv0eVuRM9rtubx1dzoaiu_crZGPnrNg@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000bcfc5b05fe9785a2"
Subject: Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with
 overloaded signatures
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--000000000000bcfc5b05fe9785a2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

HI Nicolas and Rowan,

Mate, WDYT of 2)?


Your sentence about better typing rang a bell with me: I think that's the
best argument
for removing the signature accepting callables. But before coming to a
conclusion,
let me answer Rowan's question first:

This is where I don't understand what you or Mat=C3=A9 consider to be the
> alternative. If we create any function with a new name, then we have two
> names for the user to choose between, regardless of whether that's one ol=
d
> name and one new, or two new names. That's why I'm saying that if we have
> two names at all, they should both be chosen with new users in mind, not
> fudged based on a combination of current and new naming styles.
>
> Once the deprecation period is over, we should be left with a pair of nam=
es
> that obviously signals the difference; or, we should be left with only on=
e
> function.
>

Of course, the best situation would be to have only the new function name
with a single
signature. Personally, I also prefer the OO style, but this doesn't
really matter now. However,
the sad truth is that we have a very widespread function with a slightly
incorrect name supporting
2 signatures for more than a decade...

On top of that, while most of the other deprecations in the RFC either
affect rare functionality, or are
suppressable via a simple polyfill or some automation/search+replace, only
supporting the
OO style signature of session_set_save_handler() would mean that people
would have to
wrap the callbacks in a class. This is not automatable, and requires some
possibly non-trivial manual work.
This means that we have to change anything really carefully here.

With all these in mind, I'd say that the strategic goal should be to have a
single signature +
the new function name only. Reaching this state would affect every single
proprietary codebase in some
way or another, so I don't think it's feasible or fair with users to try it
in one single step. So in order to reduce
the damage, my plan is the following:

* Let's keep one of the two signatures which are compatible with older PHP
versions so that at least a fraction of
all users (maybe 50-70%?) are not impacted at all. That's why
session_set_save_handler() should not be removed
just yet. Since the OO version seems more future-proof based on Nicolas'
great argument (it accepts an interface,
while callbacks don't have a formal signature), we should keep this form.
* People who use the signature to be deprecated should not be forced to do
non-trivial changes. So introducing
a new function for them will keep their code run with a minimal
effort (search + replace), while we managed to
eliminate the overloaded signature. At the same time, we try to educate
them (mostly in the manual) that the best
way forward is to migrate their code to use session_set_handler(). There's
no deprecation just yet, and everyone
can do it voluntarily at their own pace.
* In order to finally achieve the strategic goal, we deprecate the old
function along with session_set_handler_callbacks()
as soon as the right time comes. That may be PHP 9.x or 10.y or 11.z,
whatever.

This process may sound complicated, but in my opinion, this is the least
disruptive upgrade path for achieving the goal
I outlined above. Sometimes going full ninja mode is possible, but I'd
prefer being careful in this very case, especially
because I guess some people do not consider the motivation of the RFC
particularly important, so I would like if their
cost-benefit analysis would stay positive (I don't only mean voters but end
users as well, since their perception also
matters when they are fixing the incompatibilities of their code).

M=C3=A1t=C3=A9

--000000000000bcfc5b05fe9785a2--