Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:48847 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 56277 invoked from network); 20 Jun 2010 10:01:15 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Jun 2010 10:01:15 -0000 Authentication-Results: pb1.pair.com header.from=ulf.wendel@phpdoc.de; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=ulf.wendel@phpdoc.de; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain phpdoc.de from 212.227.17.9 cause and error) X-PHP-List-Original-Sender: ulf.wendel@phpdoc.de X-Host-Fingerprint: 212.227.17.9 moutng.kundenserver.de Received: from [212.227.17.9] ([212.227.17.9:61306] helo=moutng.kundenserver.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 50/43-21297-9E6ED1C4 for ; Sun, 20 Jun 2010 06:01:14 -0400 Received: from [192.168.2.34] (p5B06FCC7.dip.t-dialin.net [91.6.252.199]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0LorgB-1Ot2S50AIN-00fx2d; Sun, 20 Jun 2010 12:01:10 +0200 Message-ID: <4C1DE6E5.7060905@phpdoc.de> Date: Sun, 20 Jun 2010 12:01:09 +0200 User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: =?UTF-8?B?Sm9oYW5uZXMgU2NobMO8dGVy?= CC: Sebastian Bergmann , internals@lists.php.net References: <1276945220.5172.66.camel@guybrush> In-Reply-To: <1276945220.5172.66.camel@guybrush> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V01U2FsdGVkX1/bdJtHiSPxNCEBs+Uq2uUpJlFaMGRkfNgDKPg RZFPWZBePVsiosWRCWNd/K72R3WOTCFh+pbsdJPfTwwn2tgwtQ fYux+VgeRNpxeIUlUHRXAzfQVZXnYvvE6wnHBqe+pw= Subject: Re: [PHP-DEV] Remove sqlite2 from trunk From: ulf.wendel@phpdoc.de (Ulf Wendel) Johannes Schlüter schrieb: > On Sat, 2010-06-19 at 12:45 +0200, Sebastian Bergmann wrote: >> Am 19.06.2010 11:33, schrieb Patrick ALLAERT: >>> What are the possible actions/alternatives? >> I think this was already mentioned: add a BC layer to ext/mysqli so >> that the "new" extension supports the old mysql_* functions. This would >> rid us off the old ext/mysql code without breaking code that relies on >> it. > > ... while such a wrapper has about the same amount of code as the > classic mysql extension (... which is in most parts a simple wrapper > over library functions...) Or in other words: Such a wrapper doesn't > have real benefits. And any wrapper which is there by default won't change anything. People will continue to use the old API. You need to move the masses or create facts by removing ext/mysql. The latter is quite crazy considering how popular ext/mysql is. Its popularity is somewhat understandable: its old and the API is very phpish in a classical non PJAVA sense. One of the few things that could be done is adding a note to each and every ext/mysql docs page stating that one shall use ext/mysqli instead and give examples how to do it. Ulf