Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115298
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>
In-Reply-To: <122F660D-DE94-4DFE-A0E9-FEC202E89E3A@newclarity.net>
Date: Mon, 5 Jul 2021 14:05:16 +0200
Message-ID: <CAFPFaMK=qxuvQB--FLS+Jae6G4wFgMR5dn2==3T=jNudZeP0VQ@mail.gmail.com>
To: Mike Schinkel <mike@newclarity.net>
Cc: Rowan Tommins <rowan.collins@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000631df05c65f1fd0"
Subject: Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1
From: george.banyard@gmail.com ("G. P. B.")

--0000000000000631df05c65f1fd0
Content-Type: text/plain; charset="UTF-8"

On Mon, 5 Jul 2021 at 13:39, Mike Schinkel <mike@newclarity.net> wrote:

> > On Jul 5, 2021, at 7:14 AM, Rowan Tommins <rowan.collins@gmail.com>
> wrote:
> >
> > On 05/07/2021 11:46, Patrick ALLAERT wrote:
> >> Did we ever deprecated something without the immediate intention of
> >> removing it?
> >
> >
> > What would that even mean?
>
> It would mean that although the functions are available and allowed, they
> are not recommended[1].
>
>
> > Surely a deprecation, by definition, is a notice that something is going
> to be removed.
>
> I know that you, and others on this list, have chosen to define
> deprecation as including removal, but that is actually not the accepted
> definition on the web, nor is it in any way a requirement, it is just your
> preference.
>
> Indirectly from Wikipedia and voted as the top answer on StackOverflow
> here[2] (emphasis MINE):
>
> "deprecation is a status applied to software features to indicate that
> they should be avoided, typically because they have been superseded.
> Although deprecated features remain in the software, their use may raise
> warning messages recommending alternative practices, and deprecation MAY
> indicate that the feature will be removed in the future."
>
> So I am arguing for the legitimacy of retaining "deprecated" features if
> their removal would cause significant BC breakage, I'm not just trying to
> be a pendant.
>
> -Mike
> [1] https://whatis.techtarget.com/definition/deprecated
> [2] https://stackoverflow.com/questions/8111774/deprecated-meaning
>

For the PHP project deprecation means a future removal, I'm pretty sure
this is an agreed policy for the project.
E_STRICT was like Rowan said used for cases of "well you should probably
not do this but we'll accept it",
and this category has been removed.

Now if you truly want this definition of "deprecation" can I bring forward
again to "deprecate" short tags, using 'var' for object properties, all of
the SPL data structures, a bunch of extensions, using locales, and maybe to
be fancy emit one when you don't use a visibility modifier on object
methods/properties/constants, heck why not even one for not using a typed
property now that we got mixed and union types.
As you can see this opens the door to kinda everything being marked as
deprecated just to ensure another discussion needs to be held for a removal.
The policy of X being deprecated means it's going to be removed is very
clear for end users who don't need to scramble as to whether or not this
deprecation leads to a removal or not.

Best regards,

George P. Banyard

--0000000000000631df05c65f1fd0--