On Wed, Nov 28, 2012 at 8:43 AM, Anthony Ferrara <ircmax...@gmail.com>wrote:
> Patrick, > > > Sorry, but removing the E_DEPRECATED notice when moved to PECL is not > > part 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 does > > > not make sense. > > > > Absolutely! There is no reason to remove that kind of notice in the > future. > > > > 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 > > Anthony > I 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. --Kris
