On 05/07/2021 12:39, Mike Schinkel wrote:
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.
I stand corrected, I had not encountered contexts where it was defined
differently.
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.
* Foldoc (taken from the Jargon File): http://foldoc.org/deprecated
* Wiktionary: https://en.wiktionary.org/wiki/deprecated
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 general migration guide for Symfony :
https://symfony.com/doc/current/setup/upgrade_major.html#make-your-code-deprecation-free
* The Drupal Core deprecation policy:
https://www.drupal.org/about/core/policies/core-change-policies/drupal-core-deprecation-policy
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.
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.
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?
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
