Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115307
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
In-Reply-To: <62eb8eff-e671-5b3b-5e25-2a5b38160fcd@gmail.com>
Date: Mon, 5 Jul 2021 19:03:21 -0400
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <D85C91B1-7BFD-4DDD-ABAF-F9604529D7EB@newclarity.net>
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>
To: Rowan Tommins <rowan.collins@gmail.com>,
 "G. P. B." <george.banyard@gmail.com>,
 Guilliam Xavier <guilliam.xavier@gmail.com>
Subject: Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1
From: mike@newclarity.net (Mike Schinkel)

Replying in one long email to all three who replied to me:


> On Jul 5, 2021, at 8:03 AM, Guilliam Xavier =
<guilliam.xavier@gmail.com> wrote:
> Hi Mike,
>=20
> Your links speak *in general*. However this is *specifically for PHP*: =
https://www.php.net/manual/en/errorfunc.constants.php#errorfunc.constants.=
errorlevels.e-deprecated-error (*emphasis* mine)
>=20
>     E_DEPRECATED: Run-time notices. Enable this to receive warnings =
about code that *will not work in future versions*.

1. In general (no pun intended), is it a good idea for PHP to take a =
general concept and redefine its meaning?  (Rhetorical question.)

2. That link you provided speaks of not working in future versions.  =
That future version could be 5 major versions from now, doesn't have to =
be next version.

3. And most importantly, the content on that page is not written in =
immutable stone. It could just as easily be updated to say the =
following, assuming that an agreement is made to do so:=20

"Enable this to receive warnings about code constructs that are =
discouraged and MAY not work in future versions, so best for developers =
to no longer depend on it."


> As for "significant BC breakage", isn't that what major versions are =
for? (and with the current release plan, 9.0 would be for end 2025, i.e. =
4 years after 8.1)

They can be, but AFAIK there is no immutable principle in software that =
deprecated versions must be removed in the next major version.  Doing so =
or not doing is simply a choice, a decision about what is in the best =
interest of the software and its user base. And unless I misunderstand, =
nothing about the PHP project is immutable that cannot be changed by =
consensus and/or an RFC vote.=20

So I am simply making the argument that this restrictive idea that =
deprecations *must* result in removal in the next major version can do =
more harm than good in selected cases. =20

Being restrictive in our view of deprecation means we create BC-breaked =
changes when we really don't have to, and more importantly it means we =
do not signal that certain practices are to be discouraged when we =
could.

Imagine if we decided to deprecated global variables and instead =
encourage DI and/or static variables in classes? IF we could deprecate =
global without removal, I would be 100% for deprecating global. But =
given the current restrictive interpretation promoted by some, we should =
all be 0% for deprecating global.

> On Jul 5, 2021, at 8:05 AM, G. P. B. <george.banyard@gmail.com> wrote:
>=20
> For the PHP project deprecation means a future removal, I'm pretty =
sure this is an agreed policy for the project.

Can you point me to where this has been definitely agreed in the past?  =
An RFC ideally?  (Honest question.)

There is this[1] but it only says functions will usually be completely =
removed "Later" and not "next major version."   "Later" could be 5 =
versions later.

There is this[2], but it makes no mention of when, nor was it ever voted =
on.

[1] https://wiki.php.net/rfc/deprecated-modifier
[2] https://wiki.php.net/rfc/deprecated_attribute

> 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.

But the E_STRICT constant was not removed. (Ironically?)

The motivation was "to simplify our error model and resolve the =
currently unclear role of strict standards notices."  So as I read it[3] =
we are talking apples (policy) and oranges (simplify error model/improve =
clarity)

[3] https://wiki.php.net/rfc/reclassify_e_strict

> 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.

I would be 1000% for ALL of those.  Bring them on, PLEASE.

But since you wrote that I assume you think that would be a bad idea.  =
Why?

> 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.

Yes, it opens the door for doing a lot of good for PHP, IMO.

> 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.

In all my years working with other developers, I have never witnessed =
anyone "scramble" to determine if deprecation means removal. Deprecation =
has a pretty clear meaning to most developers I know. It simply means =
"not recommended."  If a developer uses a deprecated feature, they are =
"doing it wrong."

BUT, the project owner who has existing code isn't doing it wrong to =
want to continue to run their software without having to invest new =
money into refactoring because of a function removal. Unless there is a =
compelling reason such as security concern they should not have to spend =
that developer money just to use the latest version of PHP. =20

OTOH developers would benefit from being signaled to stop using =
practices when there is a consensus they practices are not good even if =
the "bad" functionally cannot be removed in the near future.

> On Jul 5, 2021, at 8:16 AM, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
> To be clear, I don't think contrasting "accepted definition" against =
"my preference" is quite right here; there are plenty of places that =
document the definition I am familiar with, e.g.

Let me clarify. When I said "your preference" I was not trying to target =
you, I was using "your" collectively to convey the preferences of all =
who prefer that interpretation.=20

And my assumption is the people who wrote the following also had a =
preference for the same interpretation.

But since you bring them up:

> * Foldoc (taken from the Jargon File): http://foldoc.org/deprecated

"Deprecated features can, unfortunately, linger on for many years." =20
(Note it does not say deprecation means "must be removed in next major =
version.")

> * Wiktionary: https://en.wiktionary.org/wiki/deprecated

"Said of a function or feature planned to be phased out, but still =
available for use." =20
(Note it says plans do be phased out but "still available," and does not =
establish any time metric for removal.")

> Removal is also specifically mentioned in official documentation for =
plenty of PHP projects, e.g.
> * The description of the "@deprecated" tag in PhpDocumentor : =
https://docs.phpdoc.org/3.0/guide/references/phpdoc/tags/deprecated.html

"The @deprecated tag declares that the associated Structural Element(s) =
will be removed in a future version"
(Note it does not specify *which* future version. As written, it could =
mean 5 majors versions from now.)

> * The Drupal Core deprecation policy: =
https://www.drupal.org/about/core/policies/core-change-policies/drupal-cor=
e-deprecation-policy

"When a new API is added, the old API will be deprecated... it will =
usually be removed in the next major version."
(Note it says "usually," not "must" which implies that at times there =
are good reasons *not* to remove.)

> * The general migration guide for Symfony : =
https://symfony.com/doc/current/setup/upgrade_major.html#make-your-code-de=
precation-free

"When the major version is released (e.g. 5.0.0), all deprecated =
features and functionality are removed."
(This is the only one that matches your interpretation. Which is not =
surprising as Symfony itself is the most draconian of well-known PHP =
frameworks. Should PHP really be as draconian as its most draconian =
framework?)

> More directly relevant, the PHP manual at =
https://www.php.net/manual/en/errorfunc.constants.php currently =
describes E_DEPRECATED as:
> > Run-time notices. Enable this to receive warnings about code that =
will not work in future versions.

As I said above, which future version?  It does not state "the next =
major version." =20

Besides, as I also said above, this could easily be clarified to provide =
an option assuming we developed a consensus on the topic.

> Obviously, that could be changed to also include "features that are =
strongly discouraged but not currently planned for removal", but I'm =
still not convinced that that would be a useful change.

I am not advocating that.  I am advocating we should consider making it:=20=


"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."

> If we can create and document a good alternative for strftime(), then =
why *not* mark it for future removal. And if we can't provide that =
alternative, what use is there in notices discouraging it?

I have no opinion pro or con on whether or not strftime() should be =
removed because I don't often use it so I don't have any idea how many =
BC breaks that it will entail.=20

Instead I replied because your email strongly implied (stated?) that =
"deprecation required removal" and I think that position is ultimately =
harmful to the language evolution because it keeps of from deprecating =
things that we should discourage but that are too widely used to remove.

-Mike

P.S. I am not going to propose we have an RFC to establish a policy =
here, but if someone with experience knowing what is and is not =
appropriate for RFCs proposed I would definitely be happy to see the =
question getting resolved, pro OR con. =20

P.P.S. And if it was an RFC I think the vote would need to be 51% vs. =
2/3rd because it is a binary decision to clarify a policy, not a change =
to existing code. There is no definitive precedent to change that was =
ever voted on (unless I am wrong and there was an RFC on this topic?)