Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120252
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>
 <D222D279-03C2-413A-A65A-67EA96EFBF88@gmail.com>
In-Reply-To: <D222D279-03C2-413A-A65A-67EA96EFBF88@gmail.com>
Date: Fri, 12 May 2023 20:17:20 +0200
Message-ID: <CAH5C8xXFTuL9Eno6FTnMqzF084NiPY-iDSebRwwxu2Dc3=tr1A@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000004de5a105fb831e92"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--0000000000004de5a105fb831e92
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
> So I would suggest rewording the options slightly:
>
> a) Deprecate in 8.3, remove in either 9.0 or 10.0
> b) Deprecate in 8.3, remove in 10.0
> c) Do not deprecate
>
> Now if the votes are a:5, b:4, c:4, we can say:
>
> - 9 people voted for deprecation in 8.3, vs 4 against
> - only 5 voted for removal in 9.0, vs 8 against
> - 9 voted for removal in 10.0, vs 4 against
>
> So we conclude that we should deprecate in 8.3, and remove in 10.0
>

While this vote format looks a bit confusing for me at the first sight, I'm
OK to apply it. Although, I don't fully agree with
the "deprecate in 8.3 and remove in 10.0" part due to the reason I wrote
about in my previous email.

In my opinion, if we want to keep a signature for around 5-7 more years
then we should really wait ~2 years with the
deprecation so that people can react voluntarily first. Libraries have to
get rid of deprecated calls in any case, otherwise
their users will surely start to complain. If they do fix these calls in
their PHP 8.x compatible code then there's much less reason
to postpone the removal with 5 more years.

The suggestion to narrow it down to a yes/no proposal in the discussion
> phase is probably even better, though.
>

I agree with this, but so far there was no feedback which functions/methods
people want to deprecate slower or faster,
so I'm eager to hear about your and everyone else's opinion!

Replying to Larry:

That these particular functions and uses are quite rare doesn't really
> change any of that; if anything it strengthens it, that we're willing to =
be
> graceful about it even in cases where we could probably get away with not
> being so.


I don't think this "generosity" is really necessary, even though I
appreciate your intention. For example,
in case of ldap_connect(), the signature to be deprecated is not even
documented at php.net... and it's only available on
a very specific platform. I see no reason to keep this signature for 5+
years. The same goes for IntlGregorianCalendar::__construct()
which seems to be a very underrepresented class as well.

As I already said, most of the functionality to be removed is easy to
replace, and it could be done via automation:
i.e. you add Symfony Polyfill to your project and then Rector swaps the
problematic function calls to the good ones. Sometimes
not even tooling is needed, a simple search + replace is enough. With all
that said, I think only a smaller subset
of functions may deserve the longer depreciation period.

M=C3=A1t=C3=A9

--0000000000004de5a105fb831e92--