Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41889
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.26.179 cause and error)
Message-ID: <491C049C.7080506@lsces.co.uk>
Date: Thu, 13 Nov 2008 10:42:36 +0000
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/20080829 SeaMonkey/1.1.12
MIME-Version: 1.0
To: PHP internals <internals@lists.php.net>
References: <42D56477-0E39-4548-B711-A950480E562E@pooteeweet.org>
In-Reply-To: <42D56477-0E39-4548-B711-A950480E562E@pooteeweet.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] quick polls for 5.3
From: lester@lsces.co.uk (Lester Caine)

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
0
> II) remove ext/mhash
0

> 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
c

> 4) keep ext/phar enabled by default in 5.3?
-1

> 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
Many people do not use MySQL so it should not be enabled by default. This is 
even more important if it gets compiled in by default in windows builds.

> 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.
Am using output buffering but don't know what effect this has.

> 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
Don't know.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php