Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41879
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 64.99.136.142 as permitted sender)
Message-ID: <027601c94503$79e5c6d0$3ffc1f3e@foxbox>
To: "Lukas Kahwe Smith" <mls@pooteeweet.org>
Cc: <internals@lists.php.net>
References: <42D56477-0E39-4548-B711-A950480E562E@pooteeweet.org>
Date: Wed, 12 Nov 2008 20:15:56 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] quick polls for 5.3
From: steph@php.net ("Steph Fox")

Hi Lukas,

> 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, BC concerns. Can't we just deprecate it in 5.3 and remove in 6.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... if it was just one extension OK, but three is too many

> 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.5.. I'd really like to see it in 5.3 because it was supposed to fix 
several OB issues, but it's probably too late in the cycle now

> 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 (not enough insight to vote on this)

Thanks,

- Steph

>
> regards,
> Lukas Kahwe Smith
> mls@pooteeweet.org
>
>
>
>
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>