Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:63893 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 43624 invoked from network); 15 Nov 2012 23:38:20 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Nov 2012 23:38:20 -0000 Authentication-Results: pb1.pair.com header.from=theanomaly.is@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=theanomaly.is@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.170 as permitted sender) X-PHP-List-Original-Sender: theanomaly.is@gmail.com X-Host-Fingerprint: 209.85.217.170 mail-lb0-f170.google.com Received: from [209.85.217.170] ([209.85.217.170:47327] helo=mail-lb0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 64/60-41238-AEC75A05 for ; Thu, 15 Nov 2012 18:38:19 -0500 Received: by mail-lb0-f170.google.com with SMTP id j14so1812428lbo.29 for ; Thu, 15 Nov 2012 15:38:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=px4LwXHKi+FQQAVwBTTG0o8eum0EjdgjN8v3vE4g5Yg=; b=aA25Xm5a87QqLcf5QtYHwtGGeaC8MQq8b0yvpVYPqLb8kESDxKKl9KPDI2y5ULrM0X /Hckvdw0olQqKKDKZoVhLHupzRD19DObUgfukzGMJ2x1iVnqNOinHfJatssC875goxww nYRsRQlJ7FY4Wv1Me+YJEwNYUwpbhE6F2kf0JbFlM/5qzbnfELlrprkS4p5gxG3YFVG4 FxgULF2baK9VR4ErZF1F66QOaoMgzUAnNlVd0yTG1eSNWygvQXpDy452YEA25SmeZxgO iK7u5ASwn2bzLbSdE12MJ6NHU8jGoTCs1T0/M9QLIhIzqRJNftX/8BjDGG9pdE9X8nAd MhGg== MIME-Version: 1.0 Received: by 10.152.145.169 with SMTP id sv9mr2690658lab.2.1353022695303; Thu, 15 Nov 2012 15:38:15 -0800 (PST) Received: by 10.112.24.37 with HTTP; Thu, 15 Nov 2012 15:38:15 -0800 (PST) In-Reply-To: References: <50A10A9D.9070402@oracle.com> <50A1946F.8010407@lerdorf.com> <50A20CCB.8090909@lsces.co.uk> <8A8A29F9E43E417FB5450D63019B2DDB@NeiRoze> <8f4231fc-6e3c-4a33-af71-2af5e7a95dfd@email.android.com> <50A2D672.7010600@gmail.com> <50A30144.5070305@phpgangsta.de> <50A3BEC0.8030607@gmail.com> <50A54713.8090102@sugarcrm.com> <50A549EB.2020408@lerdorf.com> Date: Thu, 15 Nov 2012 18:38:15 -0500 Message-ID: To: Anthony Ferrara Cc: Will Fitch , Rasmus Lerdorf , Stas Malyshev , Adam Harvey , Devis Lucato , PHP Developers Mailing List Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [PHP-DEV] RFC: ext/mysql deprecation From: theanomaly.is@gmail.com (Sherif Ramadan) On Thu, Nov 15, 2012 at 3:11 PM, Anthony Ferrara wrote: > 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 You see, I'm skeptical about this approach. Mainly because I don't see how any of that has proven to be the case in the past. Albeit, we've never deprecated such a heavily used extension before in the past, but still. There remains the issue of "how many people will actually read the manual" vs. "how many will take this as a precursor to either stop using the extension in development of new applications (we already advice against that now in the manual by the way)" vs. "how many will take action to not upgrade or fix their legacy code" vs. "how many people actually intend on upgrading to PHP 5.5 when they have legacy code dependent on ext/mysl". I think these questions need to be considered more seriously in order to re-evaluate the proposal of "delaying E_DEPRECATED for ext/mysql is really going to help people". Does any of this really help anyone affected by the deprecation of the extension? I can't possibly see how since those that are still using it will just likely not upgrade to PHP 5.5 if their legacy code can not due without ext/mysql. Your not considering the sheer number of projects that still haven't upgraded from 5.3 let alone 5.4. I really urge everyone reconsider the reality of delaying the warnings and what good that actually brings.