Hello all.
I'd like to express my feelings on the "let's-enable-it-by-default" mood that
has emerged lately.
Extensions enabled by default in 5.2:
ctype
date
dom
filter
hash
iconv
json
libxml
pcre
PDO
pdo_sqlite
posix
Reflection
session
SimpleXML
SPL
SQLite
standard
tokenizer
xml
xmlreader
xmlwriter
-----
Total: 22 extensions
Extensions enabled by default in 5.3:
ctype
date
dom
ereg
fileinfo - new, untested.
filter
hash
iconv
json
libxml
pcre
PDO
pdo_sqlite
Phar - new, untested
posix
Reflection
session
SimpleXML
SPL
SQLite
sqlite3 - new, untested
standard
tokenizer
xml
xmlreader
xmlwriter
------
Total: 26 extensions
All of the newly enabled extension are still in development and none of them
are known to be stable enough to be even included into the core, but for
some weird reason they got even enabled by default (i.e. officially recommended).
So we now have 3 (three) SQLite extensions, all of them too slow to be used in real
life (because SQLite itself is slow), two PDO extensions (unmaintained, known to cause
crashes), json (author's gone for a burton; stability and necessity is arguable),
fileinfo extension with no tests and poorly written bundled lib known to cause crashes
and we in fact *officially recommend them* by enabling them all by default.
So why should we even bother disabling something?
Let's enable everything by default, most of the users use --disable-all anyways!
I can agree that disabling something that was already enabled in 5.2 might create
some confusion, but why enable scarcely created extensions by default, especially if
they are known to cause lost of obscure problems in the past (like Phar)?
I mean completely no offense to the developers of these extensions, but
I would like them (extensions) to be thoroughly tested and mature first,
after that we can discuss the question of adding them to the core.
And no, they must not be enabled by default unless they bring some extra-useful
functionality that the engine lacks (like SPL and reflection do).
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
