Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120237
MIME-Version: 1.0
References: <CAH5C8xXtCVHaxwzmAW_eBxp_D6p7kww9svND=3AEeC9X6--YXg@mail.gmail.com>
 <ffa8138a-f1b6-3926-bc2f-558ffca344b0@gmail.com> <CAH5C8xXhCkZt7bBs7YcjMBRYM5ggu7W47huCCbVwb2-q_zFnBA@mail.gmail.com>
 <e3eba528-a015-48be-ba8e-fa71d512aa33@app.fastmail.com> <CAH5C8xVJPXx8Mk5WViOiqBe-094zTbtSO6pkZGx2BeGKbaXVoA@mail.gmail.com>
 <9ab0173f-a6f2-66f6-3ab3-d5f0c44feb05@bastelstu.be> <CA+kxMuT_DsqqH6-pq+P7ZjddEpCetHhYQvuDkAd4_oNSh7ePpA@mail.gmail.com>
In-Reply-To: <CA+kxMuT_DsqqH6-pq+P7ZjddEpCetHhYQvuDkAd4_oNSh7ePpA@mail.gmail.com>
Date: Fri, 12 May 2023 00:16:38 +0200
Message-ID: <CAH5C8xV=Smd4+idWk1bc7yZ50aqNa65u7VotGH8MmrA+Z5XFjA@mail.gmail.com>
To: Dan Ackroyd <Danack@basereality.com>
Cc: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>, 
	Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005666ca05fb72589b"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--0000000000005666ca05fb72589b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Dan and Tim,


> The RFC author could just say that yes votes for deprecation and
> eventual removal will be added together, with the timescale being a
> preference vote.
>

Thank you, Dan, for the  clarification, that was indeed what I meant. I'll
also
make this clear in the RFC, unfortunately I forgot it so far.

=E2=80=A6 the following: I wanted to know if


> "Deprecate in 8.x + not remove in 9.0, but only remove in 10.x or 11.x"


Yes, this is also a possible choice. Actually, I'm sure there were multiple
things deprecated in 5.x,
which only got removed in PHP 8.0. At least this is what I remember. :)

The reason why I still opted for the possibility of "deprecate in 9.0 and
remove in 10.0",
because in my opinion this choice would suit better some of the most
widespread functionalities.
Not deprecating them formally straightaway in 8.x versions, but only
providing a suggested
alternative instead of them, would first of all buy some time for people
who don't yet want to deal with this problem at all, but still allow them
to voluntarily migrate
when they are ready without nagging them. Then they had a relatively long
time period when we would
warn them a bit louder. A full major release cycle should be more than
enough time to perform the migration.

With all that said, personally I don't think any of the affected
functionalities (maybe with the exception
of only one of them) warrant such a long phasing out period.

Regards,
M=C3=A1t=C3=A9

--0000000000005666ca05fb72589b--