Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41874
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.94.239.7 as permitted sender)
Date: Wed, 12 Nov 2008 14:48:13 -0500 (EST)
To: Lukas Kahwe Smith <mls@pooteeweet.org>
cc: internals Mailing List <internals@lists.php.net>
In-Reply-To: <42D56477-0E39-4548-B711-A950480E562E@pooteeweet.org>
Message-ID: <alpine.DEB.2.00.0811121444470.11053@kossu.ez.no>
References: <42D56477-0E39-4548-B711-A950480E562E@pooteeweet.org>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [PHP-DEV] quick polls for 5.3
From: derick@php.net (Derick Rethans)

On Wed, 12 Nov 2008, Lukas Kahwe Smith wrote:

> 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
> II) remove ext/mhash

yes, yes

> 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

no

> 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

c

> 4) keep ext/phar enabled by default in 5.3?

yes

> 5) keep ext/sqlite3 enabled by default in 5.3?

yes

> 6) enable mysqlnd by default in 5.3? (answer both)
> I) enable mysqlnd by default
> II) also enable ext/mysql, mysqli und pdo_mysql by default since there will be
> no external dependencies in this case

no, no

> 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.
> 
> 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

a - definitely not b - there is not enough test cases, and there are way 
too many changes to see what was changed. From what I can see now, 
allowing this enormous big patch into HEAD was also a bad idea. (And 
seriously, this shouldn't have been on your list IMO).

Derick

-- 
HEAD before 5_3!: http://tinyurl.com/6d2esb
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org