Johannes Schlüter wrote:
> On Mon, 2008-11-10 at 12:41 +0200, Jani Taskinen wrote:
>> 1. Change ext/phar to be disabled by default
>
> Is that the only case? We have a few new extensions, fileinfo is enabled
> by default at the moment, hash is, sqlite3 is, ...
>
> So the question is: What's the purpose of bundling extensions and what's
> the risk? - In general I think the reason to bundle stuff is to make it
> available as "default" stuff, so enabling by default makes sense. But
> then we also have to enable more stuff without external dependencies
> (mbstring, mysqlnd [1]) and we should consider enabling by default stuff
> where header and libs are on most systems (like zlib) ... but then again
> we get a really big beast as default config.
>
> So, what's the right line?
>
I'm fine with adding more things to the default, we all know that any
distro is going to ignore what we recommend and separate it into packages.
>> 2. Change ext/ereg to be disabled by default (scheduled to be removed in
>> PHP 6, iirc?)
>
> kind of related to the previous thing, we should at least deprecate it,
> removing has benefits as it's often insecure to use ereg (barely anyone
> is aware of \0-Byte problems ...)
>
>> 3. Remove ext/mhash (replaced by ext/hash)
>
> isn't mhash just a compatibility wrapper on top of hash? Kicking that
> out is bad for getting people to migrate to 5.3.
>
The compatability stuff is in ext/hash the code in ext/mhash is purely
there for extension_loaded('mhash') though I would expect more people to
use function_exists()
Looking at google codesearch shows that its going to affect pear Crypt
and squirrelmail. I'm however fine with removing it.
Scott
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
