Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120635
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>
In-Reply-To: <d63738cf-2711-8d2a-0935-7ecdabc5c9a6@gmail.com>
Date: Tue, 20 Jun 2023 08:26:00 +0200
Message-ID: <CAOWwgpkRdKwFOWwnLciPQRxjimaGtr-ATFFCpFgB1JjH18AyQA@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000005d355905fe89baf4"
Subject: Re: Fwd: [PHP-DEV] [RFC] [Discussion] Deprecate functions with
 overloaded signatures
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--0000000000005d355905fe89baf4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le lun. 19 juin 2023 =C3=A0 22:33, Rowan Tommins <rowan.collins@gmail.com> =
a
=C3=A9crit :

> On 19/06/2023 21:17, Nicolas Grekas wrote:
> > I think we must account for a bit of history/legacy on the topic.
> > I think session_set_save_handler(SessionHandlerInterface) is the best
> BC/FC
> > path we can provide.
>
>
> Can you elaborate? The SessionHandlerInterface is the *newer* of the two
> current signatures, so what does making it the preferred signature (with
> users of the other having to change their code) have to do with
> "history/legacy"?


Sure : SessionHandlerInterface is around 5.4. It's been there since long
enough to not care about this aspect when considering both signatures. In
my experience, supporting 3 major versions is way enough: previous major,
current major and next major. Which means 7+8+9 in this case. It's enough
because an app that runs on < 5.4 doesn't need to prepare to move to 9. It
first has many more steps to do.

Then, among both options, we need to select the one with the best future
proofness, and that's definitely the OOP one to me, because it comes with
more guarantees (type checks).

By doing so, we allow apps that are still on 7 but are also actively
planning to upgrade to 8+ to make the future-proof choice of choosing
SessionHandlerInterface.

Nicolas

--0000000000005d355905fe89baf4--