Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64083
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nGoV0Q78V6sRTNkiwsj3mZDWdJyFpDgexPe7r7B4xe8=A@mail.gmail.com>
References: <CADajX4BRUFUb_Wp2a40d2vwXHeMmO611Sqrv7=oxbLHag9qOyg@mail.gmail.com>
	<CADajX4B3RctPoodShRhLLyDQW8-QFaCBOU+6PjL0FDHPGYBtzg@mail.gmail.com>
	<50B5D992.30609@lsces.co.uk>
	<CACwt+JeuSo7TOyVLUMhvQPx2duPi9aDw=HZ=qgknKi+5kVP8VA@mail.gmail.com>
	<CAAyV7nGoV0Q78V6sRTNkiwsj3mZDWdJyFpDgexPe7r7B4xe8=A@mail.gmail.com>
Date: Wed, 28 Nov 2012 12:33:55 -0800
Message-ID: <CAKOpQSzyCjMH2Rvo4n0kgbugzvwRga4SnO4URR2uqoTefG3Z6g@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: Patrick ALLAERT <patrickallaert@php.net>, Lester Caine <lester@lsces.co.uk>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8f234665d666e004cf94159c
Subject: Re: [PHP-DEV] Re: [VOTE] ext/mysql deprecation in 5.5
From: kris.craig@gmail.com (Kris Craig)

--e89a8f234665d666e004cf94159c
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 28, 2012 at 8:43 AM, Anthony Ferrara <ircmaxell@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

--e89a8f234665d666e004cf94159c--