Hello All,
First up thanks for this every efficient thread!
Really makes the life for Johannes and myself a lot easier when we can
so easily get an overview of the opinions on internals.
After having discussed the results, we want to publish our
conclusions ..
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 Lukas
+1 David C.
+1 Hannes
+1 Matt Wilson
+1 Greg
+1 Derick
+1 Elizabeth
+1 Lars
+1 Stas
+1 Ilia
+1 Steph
+1 Scott
+1 Kalle
+1 David S.P.
+1 Rob
+1 Pierre
+1 Arnaud Le Blanc
+1 Larry Garfield
+0 Lester Caine
+0 Konstantin Leboev
+1 Jani
+1 Jonathan Bond-Caron
+1 George Antoniadis
+0 Felipe
+1 Moriyoshi
+1 Karsten Dambekalns
+1 Alexey Zakhlestin
+1 Marcus
+1 Guilherme Blanco
=> keep ext/hash enabled by default
II) remove ext/mhash
+1 Lukas
+1 David
+1 Hannes
+1 Matt Wilson
+0 Greg
+1 Derick
+1 Elizabeth
+1 Lars (Probably hack ZEND_FUNCTION(extension_loaded) to return true
when "mhash" is passed and throw a deprecation warning. Is pretty easy
but ugly. What would our ZE guys suggest to accomplish something like
that?)
+1 Stas (Can't we make mhash "stub" extension with dependency on hash
so only thing you get when you load it is that extension_loaded is OK
and no BC break? Dependency would ensure the functions are there, and
we get the bets of both worlds.)
+1 Ilia
-1 Steph BC concerns. Can't we just deprecate it in 5.3 and remove in
6.0?
+1 Scott
+0 Kalle
+1 David S.P.
+1 Rob
+1 Pierre
+0 Arnaud Le Blanc
-1 Larry Garfield better to E_DEPRECATE for a version first then remove.
+0 Lester Caine
+0 Konstantin Leboev
+1 Jani
+0 Jonathan Bond-Caron
+1 George Antoniadis
+1 Felipe
+1 Moriyoshi
+1 Karsten Dambekalns
+1 Alexey Zakhlestin
+1 Marcus
+1 Guilherme Blanco
=> remove ext/mhash (someone may propose some stub/magic solution for
extension_loaded('mhash'))
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 Lukas
+1 David
+1 Hannes
+1 Matt Wilson
+1 Greg
-1 Derick
+1 Elizabeth
+1 Lars
-0.5 Stas I'd say not yet, but don't care too much.
+1 Ilia
+1 Steph
+1 Scott
+0 Kalle
+1 David S.P.
+1 Rob
+1 Pierre
+1 Arnaud Le Blanc (and allow the --without-ereg switch)
+1 Larry Garfield
+1 Lester Caine
+1 Konstantin Leboev
+1 Jani
+1 Jonathan Bond-Caron
+1 George Antoniadis
+1 Felipe
+1 Moriyoshi
+1 Karsten Dambekalns
+1 Alexey Zakhlestin
+1 Marcus
+1 Guilherme Blanco
=> deprecate ext/ereg and remove in PHP 6
3) resource constants (choose one)
+0 Stas
+0 Larry Garfield
+0 Konstantin Leboev
a) Should we deprecate constant resources (mostly used to emulate
STDIN and friends)
+1 Scott
+1 Arnaud Le Blanc
+1 George Antoniadis
+1 Moriyoshi
b) Should we instead just throw an E_STRICT
+1 Kalle
c) Document as is
+1 Lukas
+1 David
+1 Hannes
+1 Matt Wilson
+1 Greg
+1 Derick
+1 Elizabeth
+1 Lars
+1 Ilia
+1 Steph
+1 David S.P.
+1 Rob
+1 Pierre
+1 Lester Caine
+1 Jani
+1 Jonathan Bond-Caron
+1 Felipe
+1 Karsten Dambekalns
+1 Alexey Zakhlestin
+1 Marcus
+1 Guilherme Blanco
=> document as is
4) keep ext/phar enabled by default in 5.3?
+1 Lukas
+1 David
-1 Hannes
-1 Matt Wilson
+1 Greg
+1 Derick
+1 Elizabeth
+1 Lars
+1 Stas
+0 Ilia
+1 Steph
+0 Scott
+1 Kalle
+1 David S.P.
+0 Rob
+0 Pierre
+1 Arnaud Le Blanc
+0 Larry Garfield
-1 Lester Caine
+0 Konstantin Leboev
-1 Jani
+1 Jonathan Bond-Caron
+1 George Antoniadis
+1 Felipe
+1 Moriyoshi
+1 Karsten Dambekalns
+1 Alexey Zakhlestin
+1 Marcus
+1 Guilherme Blanco
=> keep ext/phar enabled
5) keep ext/sqlite3 enabled by default in 5.3?
+1 Lukas
+1 David
+0 Hannes
-1 Matt Wilson
+1 Greg
+1 Derick
+1 Elizabeth
+1 Lars
+1 Stas
+1 Ilia
+1 Steph
+1 Scott
+0 Kalle
+1 David S.P.
+1 Rob
+1 Pierre
+1 Arnaud Le Blanc
+1 Larry Garfield
-1 Lester Caine
+1 Konstantin Leboev
+1 Jani
+0 Jonathan Bond-Caron
-1 George Antoniadis
+1 Felipe
+1 Moriyoshi
+1 Karsten Dambekalns
+1 Alexey Zakhlestin
+0 Guilherme Blanco
+1 Marcus
=> keep ext/sqlite3 enabled
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
-1 Lukas
-1 David
-0 Hannes
-1 Matt Wilson
+0 Greg
-1 Derick
+0 Elizabeth
+1 Lars
+0 Stas
-1 Ilia
+1 Steph
+1 Scott
+1 Kalle
+0 David S.P.
-1 Rob
+1 Pierre
+0 Arnaud Le Blanc
+1 Larry Garfield
-1 Lester Caine 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.
+0 Konstantin Leboev
+1 Jani
-1 Jonathan Bond-Caron would favor mysql by including client in
default installation (Clarification by Johannes: mysqlnd is a PHP-
specific replacement for the MySQL Client Library (libmysql) so adding
mysqlnd as default means "including client in default installation".
By using mysqlnd there are no external dependencies left.)
+1 George Antoniadis
+1 Felipe
-1 Moriyoshi
+0 Karsten Dambekalns
+1 Alexey Zakhlestin
-1 Guilherme Blanco
+0 Marcus
=> do not enable by default since there is not enough support to add
something (assumption when in doubt do not add)
II) also enable ext/mysql, mysqli und pdo_mysql by default since there
will be no external dependencies in this case
-1 Lukas
+1 David
-0 Hannes
-1 Matt Wilson
+0 Greg
-1 Derick
+0 Elizabeth
+1 Lars
+0 Stas
-1 Ilia
-1 Steph if it was just one extension OK, but three is too many
-1 Scott, i'd like to see ext/mysql removed
+1 Kalle
+0 David S.P.
-1 Rob
+1 Pierre
+0 Arnaud Le Blanc
+1 Larry Garfield
-1 Lester Caine
+0 Konstantin Leboev
+1 Jani
-1 Jonathan Bond-Caron
+1 George Antoniadis
+1 Felipe
-1 Moriyoshi
+0 Karsten Dambekalns
-1 Alexey Zakhlestin
-1 Guilherme Blanco
+0 Marcus
=> since 6)I) was not accepted this vote is not relevant, albeit its
also not clear enough to change anything
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.
-1 Lukas
-1 David
+1 Hannes
+0 Matt Wilson
+0 Greg
+0 Derick
+1 Elizabeth
+0 Lars
-1 Stas for now Need more explanation why we need rewrite, what the
rewrite does, etc. If there's a good reason and maintainer, then maybe
+1.
-1 Ilia
+0.5 Steph 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
+0 Scott
+1 Kalle
-1 David S.P. for now Need more explanation why we need rewrite, what
the rewrite does, etc. If there's a good reason and maintainer, then
maybe +1.
-1 Rob
+1 Pierre (if it creates non fixable issues during the alpha/RC
phases, it can always be reverted. However the code is much cleaner
and easier to maintain, if I can use the word "easy" for the OB code)
+0 Arnaud Le Blanc
+0 Larry Garfield
+0 Lester Caine
+0 Konstantin Leboev
+1 Jani
+0 Jonathan Bond-Caron
+0 George Antoniadis
+1 Felipe
+1 Moriyoshi
+0 Karsten Dambekalns
+0 Alexey Zakhlestin
+1 Guilherme Blanco
+1 Marcus
=> no MFH, very unclear vote result and nobody that raised their hand
to take responsibility (yes Pierre I know that you raised your hand on
IRC)
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
+0 Greg
+0 Lars
+0 Steph
+0 Kalle
+0 Arnaud Le Blanc
+0 Larry Garfield
+0 Lester Caine
+0 Konstantin Leboev
+0 Jonathan Bond-Caron
+0 Felipe
+0 Karsten Dambekalns
+0 Guilherme Blanco
a) revert in HEAD
+1 Derick 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).
+1 Stas for now Need more explanation why we need rewrite, what the
rewrite does, etc. If there's a good reason and maintainer, then maybe
+1.
+1 David S.P. for now Need more explanation why we need rewrite, what
the rewrite does, etc. If there's a good reason and maintainer, then
maybe +1.
+1 Jani
b) MFH to 5.3
+1 Lukas
+1 David
+1 Hannes
+1 Matt Wilson
+1 Elizabeth
+1 Ilia
+1 Scott
+1 Rob
+1 Pierre (there is tests, there is people taking of it if there are
issues,
more tests can be added as wish, it removes duplicate codes)
+1 George Antoniadis
+1 Moriyoshi
+1 Alexey Zakhlestin
+1 Marcus
=> Derick is the maintainer of ext/mcrypt and he opposes the change
due to the lack of tests, so anyone willing to write more tests? then
again on gcov mcrypt shows up with 88%, which looks decent, but
obviously this number does not tell the entire story. also alot of
people felt it would be good to MFH, so Derick please take this into
account.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
