Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63911
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.216.170 cause and error)
Message-ID: <50A5FB0C.1080602@lerdorf.com>
Date: Fri, 16 Nov 2012 00:36:28 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2
MIME-Version: 1.0
To: Pierre Joye <pierre.php@gmail.com>
CC: Anthony Ferrara <ircmaxell@gmail.com>, Will Fitch <willfitch@php.net>, 
 Stas Malyshev <smalyshev@sugarcrm.com>,
 Adam Harvey <aharvey@php.net>, Devis Lucato <devis@lucato.it>, 
 PHP Developers Mailing List <internals@lists.php.net>
References: <CADajX4CYZdNpgQv46m_6J7tQLBc=h6HxCn-bGpxr3Ou2VaqgBg@mail.gmail.com> <CAPwsocH3_qHSZbLFe27qX+KgBAC1D8KhwLi+PLHW503sCTBtTw@mail.gmail.com> <50A1946F.8010407@lerdorf.com> <50A20CCB.8090909@lsces.co.uk> <8A8A29F9E43E417FB5450D63019B2DDB@NeiRoze> <8f4231fc-6e3c-4a33-af71-2af5e7a95dfd@email.android.com> <CAAyV7nFOGa7UVALSQyAs-A+R0kuEmXoHPrxvCXNBnzAxLy0dww@mail.gmail.com> <50A2D672.7010600@gmail.com> <50A30144.5070305@phpgangsta.de> <50A3BEC0.8030607@gmail.com> <CAET_qdMmhRyidM6_VOokBu6tYvgrPHMOPdzz0PaFpxc3NaTdYQ@mail.gmail.com> <CADajX4Bh+5YrCPEFLzC2qqeJ4NnADbBV0u+wByz3Kb7Jp45KOw@mail.gmail.com> <50A54713.8090102@sugarcrm.com> <CAArmra2bjj3y2UUV8nszU74tN9o4VvB67aXzq5Z1cE2Y_tVijg@mail.gmail.com> <50A549EB.2020408@lerdorf.com> <CAArmra2BCmbOjkK0D8gKc5o0Pwhx0jNGi-3m2C2Z2dAnb0yv7w@mail.gmail.com> <CAAyV7nGMi20xjBYbouvsyUrxdOSuboP6u-guY9DX8qkSagQbjg@mail.gmail.com> <CAEZPtU6mbLnaqijx3T942pULm-Y6a-4LPyk-H-WJ94NckkKbfw@mail.gmail.com>
In-Reply-To: <CAEZPtU6mbLnaqijx3T942pULm-Y6a-4LPyk-H-WJ94NckkKbfw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: ext/mysql deprecation
From: rasmus@lerdorf.com (Rasmus Lerdorf)

On 11/15/2012 11:27 PM, Pierre Joye wrote:
> hi Anthony,
> 
> On Thu, Nov 15, 2012 at 9:11 PM, Anthony Ferrara <ircmaxell@gmail.com> wrote:
> 
>>> Actually, no it wouldn't. You still get the overhead of the error, plus
>>>> any custom error handlers will be triggered regardless of the
>>>> error_reporting setting which depending on the implementation of the
>>>> error handler can be quite costly performance-wise.
>>>>
>>>
>>> So what solution is there to this? Should it not be deprecated? This same
>>> issue (is still happening) with register_globals for us, but it's
>>> acceptable as it has been phased out.  Should there be no deprecation
>>> warning now and wait for a future release?
>>>
>>
>> That's my suggestion. Officially deprecate it, but don't add E_DEPRECATED
>> to it in 5.5. Update the documentation, and start a PR campaign to get off
>> it. Then in NEXT add E_DEPRECATED and in NEXT+1 remove it.
> 
> This does not make sense, at all.
> 
> We introduce this flag and used it already a lot in many parts of PHP
> (engine included) for this exact purpose. Most major apps have mysqli
> support or provide working solutions to support mysqli, incl. for
> plugins (like wordpress, which is likely to support mysqli in Q2
> 2013).
> 
> Not adding the E_DEPRECATED flag would be a mistake and will only add
> more confusions by the time we will move it out.

Actually we have never used E_DEPRECATED to deprecate an entire
extension. We have deprecated specific functions and engine features,
but for entire extensions we have provided alternatives and/or waited
for them to become inconsequential and then moved them to pecl. But we
certainly never littered the extension with warnings before moving it out.

How do you see adding E_DEPRECATED working here? Do we add it to every
function in the extension? Just to some? And then when we move the
extension to pecl do we pull the warnings back out? Surely it makes no
sense to move an extension out of core to pecl and spew E_DEPRECATED
warnings to people who explicitly choose to install it.

-Rasmus