Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63887
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAArmra2BCmbOjkK0D8gKc5o0Pwhx0jNGi-3m2C2Z2dAnb0yv7w@mail.gmail.com>
References: <CADajX4CYZdNpgQv46m_6J7tQLBc=h6HxCn-bGpxr3Ou2VaqgBg@mail.gmail.com>
	<50A10A9D.9070402@oracle.com>
	<CAAyV7nF2tt6HtFZKevH_2kknqOvEmLJjEOF2_Bn_VHaZFUJERw@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>
Date: Thu, 15 Nov 2012 15:11:20 -0500
Message-ID: <CAAyV7nGMi20xjBYbouvsyUrxdOSuboP6u-guY9DX8qkSagQbjg@mail.gmail.com>
To: Will Fitch <willfitch@php.net>
Cc: Rasmus Lerdorf <rasmus@lerdorf.com>, 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: multipart/alternative; boundary=f46d0418262a265a2a04ce8e4191
Subject: Re: [PHP-DEV] RFC: ext/mysql deprecation
From: ircmaxell@gmail.com (Anthony Ferrara)

--f46d0418262a265a2a04ce8e4191
Content-Type: text/plain; charset=ISO-8859-1

Will,


> 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. But I've said it
a number of times, and it appears that I'm the only one who thinks that
it's a good idea to take it slow and give users time to move off it...

Anthony

--f46d0418262a265a2a04ce8e4191--