Replying in one long email to all three who replied to me:
> On Jul 5, 2021, at 8:03 AM, Guilliam Xavier <guilliam.xav...@gmail.com> wrote: > Hi Mike, > > 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) > > 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: "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. 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. 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.bany...@gmail.com> wrote: > > 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. 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.coll...@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. 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." (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." (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-core-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-deprecation-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." 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: "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. 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. 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?) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
