Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115319
MIME-Version: 1.0
References: <CAF+90c96J7dyq1KsgoPTndM09V=oj46cXm0SxjfkJXiL3TjdHg@mail.gmail.com>
 <CACwt+JfrMa3h2GfG0cxNFmJeg3mPDzf6QWV44zuz+xYBqUsJfg@mail.gmail.com>
 <1dcefcec-a3e4-e773-4950-b11d377ecc7f@gmail.com> <122F660D-DE94-4DFE-A0E9-FEC202E89E3A@newclarity.net>
 <62eb8eff-e671-5b3b-5e25-2a5b38160fcd@gmail.com> <D85C91B1-7BFD-4DDD-ABAF-F9604529D7EB@newclarity.net>
 <586591d0-8bbc-a42c-f92b-819b8fc6ac20@gmail.com>
In-Reply-To: <586591d0-8bbc-a42c-f92b-819b8fc6ac20@gmail.com>
Date: Tue, 6 Jul 2021 14:24:51 +0200
Message-ID: <CAJmjfvXjQu-n699DkQWwBzRBdm3hjosz6o0Cxwy5AntFOua17A@mail.gmail.com>
To: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1
From: jakob@givoni.dk (Jakob Givoni)

On Tue, Jul 6, 2021 at 10:30 AM Rowan Tommins <rowan.collins@gmail.com> wrote:
>
> Hi Mike,
>
>
> > Instead I replied because your email strongly implied (stated?) that "deprecation required removal"
>
> I stand by that interpretation, which while not universal is very widely
> used, and I think is more useful than a general hint at "bad practice".
>
> You spend most of your e-mail seeming to argue against it, and then seem
> to say that actually you do agree with it after all, and all you're
> saying is that sometimes the deprecation period should be longer:
>
>
> > I am not advocating that.  I am advocating we should consider making it:
> >
> > "features that are strongly discouraged will*probably*  be removed in the next major version, but in some cases may be retained for one or more major versions."
>
> I'm totally OK with that.
>
> I do think that there should be a clear *plan* for removing each
> deprecated feature, though. That plan might be "deprecate in 8.1, and
> examine prior to 9.0 whether usage has dropped / the alternatives are
> mature / etc". It might flat out be "deprecate in 8.1, but don't remove
> until 10.0".
>
> Otherwise, the message becomes "this feature is kind of bad, and at some
> point we might decide to drop it without further notice, but actually we
> might not, so no hurry to remove it", which I just think isn't that helpful.
>

I think it would be very helpful.
I would have loved to know that FILTER_SANITIZE_STRING was not
considered a good choice when I recently researched how to improve an
issue.
Deprecation without a fixed removal version is better than no
deprecation (because removal version was not agreed on).

Actually I agree with everything that Mike said previously and I
strongly suggest a policy that looks like this:

Deprecation means no longer encouraged (strongly) and might be removed
in a future (major) version.
Before every new major version, review all deprecated features/usages
and decide with a simple RFC if each of them should be removed,
reviewing the current usage level and migration paths.

Best,
Jakob