Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63912
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.42 as permitted sender)
MIME-Version: 1.0
Sender: patrick.allaert@gmail.com
In-Reply-To: <50A5FB0C.1080602@lerdorf.com>
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>
	<50A5FB0C.1080602@lerdorf.com>
Date: Fri, 16 Nov 2012 09:51:18 +0100
Message-ID: <CACwt+Jdo6WO+VtYp6zSVM+a1GVGQHPxtPT4AAFz2=fQRuxvTWQ@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Pierre Joye <pierre.php@gmail.com>, 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>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] RFC: ext/mysql deprecation
From: patrickallaert@php.net (Patrick ALLAERT)

Rasmus,

As per the RFC: adding E_DEPRECATED only in mysql_connect(),
mysql_pconnect(). Which means only one error (normally) by request.

2012/11/16 Rasmus Lerdorf <rasmus@lerdorf.com>:
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



-- 
Patrick Allaert
---
http://code.google.com/p/peclapm/ - Alternative PHP Monitor