Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120654
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-499-gf27bbf33e2-fm-20230619.001-gf27bbf33
Mime-Version: 1.0
Message-ID: <7f94ae6a-9c4c-4090-8a6e-d628064b575d@app.fastmail.com>
In-Reply-To: 
 <CALKiJKpmnDr08W6DaY=m1L6u4DMLwPRFxxevvB2NT2cQnFFCVA@mail.gmail.com>
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>
Date: Wed, 21 Jun 2023 13:22:36 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded
 signatures
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Jun 21, 2023, at 11:57 AM, Rowan Tommins wrote:
> On Wed, 21 Jun 2023 at 09:43, M=C3=A1t=C3=A9 Kocsis <kocsismate90@gmai=
l.com> wrote:
>
>> The reason why I think it's a good approach to have an intermediate s=
tate
>> is to give
>> these people the possibility to defer the actual migration until the
>> very end.
>>
>
>
> Isn't that exactly what a deprecation period is for?
>
> If we want to give people longer, just leave the functionality depreca=
ted
> for longer before removing it. If we want to phase that in gradually, =
start
> 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.
>
> Regards,
> --=20
> Rowan Tommins
> [IMSoP]

I'm inclined to agree here, I think.  I am all for a very-long grace per=
iod to give people lots of time for this change, but if the end state is=
 just the object version being supported, then adding functions in the m=
ean time doesn't make sense to me.

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 forc=
ed to change.  That should be ample time for anyone that still needs to =
make the switch.

(A generic "functions to object wrapper" class is probably a not-too-har=
d composer package for someone to write, either, but that's not a task f=
or internals.)

--Larry Garfield