Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120657
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>
 <CAH5C8xU=wae81qcCPuvEv0eVuRM9rtubx1dzoaiu_crZGPnrNg@mail.gmail.com>
 <CA+hqhpd=eOW6peBH1XH8xgE8guJpX9RXLnx983wQ35kygWeHEA@mail.gmail.com>
 <CAH5C8xUrJy6HnNeJM6XzSbjCouYAFnnRxsJx8aHOQwi=a2=H6w@mail.gmail.com> <CALKiJKpmnDr08W6DaY=m1L6u4DMLwPRFxxevvB2NT2cQnFFCVA@mail.gmail.com>
In-Reply-To: <CALKiJKpmnDr08W6DaY=m1L6u4DMLwPRFxxevvB2NT2cQnFFCVA@mail.gmail.com>
Date: Thu, 22 Jun 2023 12:00:09 +0200
Message-ID: <CAH5C8xXs=L3-Gm7fvBSh5EZ16HgQ78a7mR1FDPoW-ET2R=4VDw@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000da96fc05feb4f3ce"
Subject: Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with
 overloaded signatures
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--000000000000da96fc05feb4f3ce
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Rowan and Larry,


> Isn't that exactly what a deprecation period is for?
>

Yes, sure, but I wrote my arguments with the "Short deprecation period" in
mind so that the removal of
these functions causes the least pain.


> If we want to give people longer, just leave the functionality deprecated
> for longer before removing it. If we want to phase that in gradually, sta=
rt
> with a documentation-only deprecation, and add the deprecation notice
> later.



> If the plan is to keep the current function name, we can't get any of the
> (very small) benefits of removing the extra signature until the final
> removal anyway.
>

I don't completely understand this sentence, but my current plan is to go
with the original function
name as this causes the least impact and at the same time makes the scope
of the RFC
smaller. I'm tired of the debates (even if they were useful), and I don't
want to add any tangentially
related things in the RFC anymore. Anyway, adding an alias
(session_set_handler()) and/or deprecating
the original function name later is trivial, if someone wants to pursue
this.


> I'd propose a doc-only deprecation now (with session_set_handler() added
> for the object version),

an E_DEPRECATED in 9.0, and full removal in 10.0.  Assuming the expected
> release schedule,

that gives people ~2 years before they see even an E_DEPRECATED, and 6-7
> years before they

are forced to change. That should be ample time for anyone that still needs
> to make the switch.


I want to keep the original voting choices (the short and long path). Then
votes can decide how much
notice period they want to give. Since I don't insist on changing the
function name anymore,
the impact of this change is a lower, as only people using the callback
signature would be affected.
The fortunate thing is that session handling is used less in library code
so at least open source maintainers
rarely have to deal with the deprecation. And proprietary code maintainers
can mostly ignore or suppress it
for a while.

Regards,
M=C3=A1t=C3=A9

--000000000000da96fc05feb4f3ce--