Re: Re: [VOTE] ext/mysql deprecation in 5.5
| From: | David Muir | Date: | Thu, 29 Nov 2012 01:55:35 +0000 |
| Subject: | Re: Re: [VOTE] ext/mysql deprecation in 5.5 | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-64089@lists.php.net to get a copy of this message | ||
On 29/11/12 07:33, Kris Craig wrote:
On Wed, Nov 28, 2012 at 8:43 AM, Anthony Ferrara <ircmaxell@gmail.com>wrote:Kris, There was no "ext/magic_quotes" that was retired to PECL. You're comparing apples with oranges. DavidPatrick, Sorry, but removing the E_DEPRECATED notice when moved to PECL is notI think we're over-complicating this a bit. The whole point of E_DEPRECATED is to get people to stop using an obsolete feature before it's removed (or moved to PECL or whatever; neither of which is in the scope of this RFC anyway). Documentation and whatnot can only accomplish so much. We also know that E_DEPRECATED works when other approaches do not. I would point you all to the famous example of Drupal 7, which would break completely due to a flurry of E_DEPRECATED warnings (if display_errors was set to on) being triggered as of 5.3 due to their continued use of magic_quotes_gpc and magic_quotes_runtime. When Drupal 8 was released some time later, the code was fixed so that it no longer used those out-dated functions. That's why I voted yes. --Krispart of the proposed RFC and should certainly not happen.The proposal doesn't actually propose anything about a move to PECL. It's listed in the "possible future actions" section exactly once. But the RFC doesn't take a stand on it in either direction. So I'm not sure that you can make that argument.Adding it in one location and not the other doesfuture. That's your opinion. Please realize it as such and that other viewpoints also exist. For example, I have the viewpoint that deprecation applies to the LANGUAGE. The inclusion of the extension in the language is what's being deprecated. Even after it's pulled, someone else can maintain it. We can say that you should avoid it, but there's nothing stoping someone else from continuing maintenance of it as a fork. And adding in the other missing functionality (possibly breaking BC, possibly not, whatever). Therefore, in my viewpoint, the deprecation notices only apply to the inclusion of the extension in the core language distribution. Not to the extension itself. I'm not saying that either one of us is right or wrong, just that there are other opinions. To keep this discussion productive, please refrain from using absolutes like that... Thanks Anthonynot make sense.Absolutely! There is no reason to remove that kind of notice in the