Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:63899 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 54980 invoked from network); 16 Nov 2012 01:16:42 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Nov 2012 01:16:42 -0000 Authentication-Results: pb1.pair.com header.from=davidkmuir@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=davidkmuir@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.42 as permitted sender) X-PHP-List-Original-Sender: davidkmuir@gmail.com X-Host-Fingerprint: 209.85.220.42 mail-pa0-f42.google.com Received: from [209.85.220.42] ([209.85.220.42:62213] helo=mail-pa0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C9/50-52800-9F395A05 for ; Thu, 15 Nov 2012 20:16:42 -0500 Received: by mail-pa0-f42.google.com with SMTP id fa1so1482689pad.29 for ; Thu, 15 Nov 2012 17:16:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=yV2zuZlsJopoDgUJzdiWpMAAv2wQNcGRdCYZUWuKK0o=; b=khX3kE3eto4zI4zRVrcdo5dUgS/6YPxzQLSxWdAhl2SeQZT+uD5/JE1DOS+eLhVeas EKMO5DBf2DMrC9Y+8RuHVNYjyU7IlRYLy/IXfOhGCJ/DDgub5jekrW43Ro/sjcjImi/E Rica7WTzhRmGCSuf/GyzF+PUqPt8Pvm04pcelOrZKCxmzKtXYpsG4M9uCLPcRmgvfUJF qrGyqJQPN62FXOyGzsTgoBdqjTsMthlOLf8tyT5hkDANpEQ7CctK5T2pmvJMchybpm+C +10qbnZcp+/JOSdjPIv+jfne4hTjT1UEPT9/f4iNNqO+okjXABrnOVp9uQ7xz8n/eM74 03BA== Received: by 10.68.219.106 with SMTP id pn10mr9972415pbc.98.1353028598677; Thu, 15 Nov 2012 17:16:38 -0800 (PST) Received: from [192.168.0.5] (115-64-165-88.static.tpgi.com.au. [115.64.165.88]) by mx.google.com with ESMTPS id ay5sm108158pab.1.2012.11.15.17.16.35 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 17:16:37 -0800 (PST) Message-ID: <50A593F2.5020800@gmail.com> Date: Fri, 16 Nov 2012 12:16:34 +1100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Adam Harvey CC: Anthony Ferrara , PHP internals References: <50A10A9D.9070402@oracle.com> <50A1946F.8010407@lerdorf.com> <50A20CCB.8090909@lsces.co.uk> <8A8A29F9E43E417FB5450D63019B2DDB@NeiRoze> <8f4231fc-6e3c-4a33-af71-2af5e7a95dfd@email.android.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] RFC: ext/mysql deprecation From: davidkmuir@gmail.com (David Muir) On 14/11/12 03:17, Adam Harvey wrote: > On 14 November 2012 00:07, Anthony Ferrara wrote: >> There's one important thing that I think you all are missing here. You keep >> bringing up that we should just use the normal "deprecation" process. The >> problem is that the deprecation process was never designed for a feature >> like this. > Serious question: what was it designed for, then? This (along with > magic quotes, and register globals) was always what I had in the back > of my mind when it was being discussed. > > There are two big differences here. The first is that ext/mysql is still *very* widely used. Secondly, the deprecation process (throwing deprecation warnings, then removal) should not be applied to *extensions* anyway. Magic quotes and register globals were PHP engine features. There was no other "user friendly" way to get rid of them, because once gone, it's gone. (Ok, they could have maybe been made into an extension, but nobody wanted that anyway...). The deprecation process here should similar to the process used for other extensions that have been retired/removed from core (Crack, mhash, sybase, ming, msql, fdf, fbsql, dbase, filePro, Hyperwave, etc) 1. Add "remove from core" status in documentation with notice about maintenance dropping after 5.next 2. Remove it from core (those who still need it can pull from PECL) 3. If the community needs it after 5.next, then they'll have to step up and maintain it themselves. The point is, an extension should never be throwing deprecation warnings for a planned migration to PECL. Cheers, David