Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:41888 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 52484 invoked from network); 13 Nov 2008 04:27:17 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Nov 2008 04:27:17 -0000 Authentication-Results: pb1.pair.com header.from=larry@garfieldtech.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=larry@garfieldtech.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 76.96.30.32 cause and error) X-PHP-List-Original-Sender: larry@garfieldtech.com X-Host-Fingerprint: 76.96.30.32 qmta03.emeryville.ca.mail.comcast.net Received: from [76.96.30.32] ([76.96.30.32:42444] helo=QMTA03.emeryville.ca.mail.comcast.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 83/90-07308-3ACAB194 for ; Wed, 12 Nov 2008 23:27:16 -0500 Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id eQcT1a00D0mlR8UA3UTDoU; Thu, 13 Nov 2008 04:27:13 +0000 Received: from earth.ufp ([24.13.255.226]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id eUTB1a00B4trKQ88XUTCM2; Thu, 13 Nov 2008 04:27:12 +0000 X-Authority-Analysis: v=1.0 c=1 a=xkS-QZRiz0IA:10 a=adlDL0BXA6brI1km0SoA:9 a=1a9XSkjXQBh1b1jjgooA:7 a=B51ZA3wOtnvpb1hDeaVlEJZUIuAA:4 a=FHBbIDN7CdwA:10 a=LY0hPdMaydYA:10 Received: from localhost (localhost [127.0.0.1]) by earth.ufp (Postfix) with ESMTP id 7C53AD7A1F for ; Wed, 12 Nov 2008 22:27:11 -0600 (CST) Received: from earth.ufp ([127.0.0.1]) by localhost (earth.ufp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTu-7eGAxe2U for ; Wed, 12 Nov 2008 22:27:10 -0600 (CST) Received: from luna.localnet (unknown [192.168.42.1]) by earth.ufp (Postfix) with ESMTPSA id 75569D7A04 for ; Wed, 12 Nov 2008 22:27:09 -0600 (CST) To: internals@lists.php.net Date: Wed, 12 Nov 2008 22:27:08 -0600 User-Agent: KMail/1.10.1 (Linux/2.6.27-7-generic; KDE/4.1.2; i686; ; ) References: <42D56477-0E39-4548-B711-A950480E562E@pooteeweet.org> In-Reply-To: <42D56477-0E39-4548-B711-A950480E562E@pooteeweet.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <200811122227.08181.larry@garfieldtech.com> Subject: Re: [PHP-DEV] quick polls for 5.3 From: larry@garfieldtech.com (Larry Garfield) On Wednesday 12 November 2008 1:14:31 pm Lukas Kahwe Smith wrote: > Hi, > > here are a few questions that need to be answered ASAP. > > If at all possible keep your votes as short as possible. I think all > of the above topics have been discussed quite a lot on the list. So I > hope voters can spare the list needless repetition. Instead if you > think that a topic needs to be discussed, put a short note in your > vote under the given topic. If a number of people also think the topic > needs more discussion, then we can open a new thread dedicated to this > topic later this week. > > 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC > break will be that "if (extension_loaded('mhash'))" will need fixing > if mhash is removed (answer both) > I) enable ext/hash by default +1 > II) remove ext/mhash -1, better to E_DEPRECATE for a version first then remove. > 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ > ereg is more or less redundant with ext/preg and is likely to not get > much unicode love for PHP 6, the question is if we should mark it with > a E_DEPRECATED in PHP 5.3 +1 > 3) resource constants (choose one) > a) Should we deprecate constant resources (mostly used to emulate > STDIN and friends) > b) Should we instead just throw an E_STRICT > c) Document as is +0 > 4) keep ext/phar enabled by default in 5.3? +0 > 5) keep ext/sqlite3 enabled by default in 5.3? +1 > 6) enable mysqlnd by default in 5.3? (answer both) > I) enable mysqlnd by default +1 > II) also enable ext/mysql, mysqli und pdo_mysql by default since there > will be no external dependencies in this case +1 > 7) should Output buffering rewrite MFH? this one comes with some > baggage, we need enough people to actually have a look at how things > are in HEAD and make it clear that they will be available for bug > fixing and BC issues resolving. the risk here is obviously that any BC > issues will be hard to isolate for end users. +0 > 8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so > either (choose one) > a) revert in HEAD > b) MFH to 5.3 +0 -- Larry Garfield larry@garfieldtech.com