Its been about a week since RFS for features to go into 5.3 has gone
out and while there was not a "flood" of ideas there is a substantial
list of key changes people would like to go into this release. I've
compiled a list of all of the suggestions I've received, they are
listed below in a form that will hopefully make it easy for people to
vote their yeys and nays. My hope that we can reach an agreement
within 1-2 weeks so 5.3 can be branched and work on it can begin.
List of Feature Ideas
- Backport the namespaces patch for PHP 6
1 0 -1
- Symlink the intl extension from PECL, but leave it disabled by
default as is the case with all extensions dependent on external libs
1 0 -1
- Apply the Late Static Binding Patch
1 0 -1
- Implement David's Circular Garbage collection patch
1 0 -1
- Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)
1 0 -1
- Remove safe_mode, register_globals and magic_quotes
1 0 -1
- Introduce mysqlind library into core and use it as a backend for
PDO and mysqli extensions (possibly enabling them by default)
1 0 -1
- OpenID enabling patch for OpenSSL and PHP 5
1 0 -1
- Add array_replace[_recursive] functions (patch is already available)
1 0 -1
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
1 0 -1
- Merge the zend_arg_info const'ify patch
1 0 -1
- Merge the GCC 4 -fvisibility patch
1 0 -1
- Switch for disabling/enabling materialized cursors in mysqli
1 0 -1
- Link phar extension from PECL into core (possibly enabling it by
default)
1 0 -1
- Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
1 0 -1
- Introduce new php.ini files parser/scanner + CGI/FastCGI?
"htaccess" style ini file support
1 0 -1
- Merge __callStatic patch from PHP 6
1 0 -1
- Introduce concept of "strict classes" that do not permit dynamic
property creation
1 0 -1
Ilia Alshanetsky
Its been about a week since RFS for features to go into 5.3 has gone
out and while there was not a "flood" of ideas there is a substantial
list of key changes people would like to go into this release. I've
compiled a list of all of the suggestions I've received, they are
listed below in a form that will hopefully make it easy for people to
vote their yeys and nays. My hope that we can reach an agreement
within 1-2 weeks so 5.3 can be branched and work on it can begin.
Response from a random PHP guy who doesn't work on the engine itself (so take
with appropriate quantities of NaCl):
List of Feature Ideas
- Backport the namespaces patch for PHP 6
1
- Symlink the intl extension from PECL, but leave it disabled by
default as is the case with all extensions dependent on external libs
I have no opinion.
- Apply the Late Static Binding Patch
-1, unless we can guarantee no BC breakage with 5.2.
- Implement David's Circular Garbage collection patch
I am not qualified to offer an intelligent opinion.
- Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)
1
- Remove safe_mode, register_globals and magic_quotes
-1
These must die, but that's also a huge BC break, even if those are already
unrecommended. That would almost certainly slow adoption by shared hosts,
which means that 5.3 would have a 5.0-like adoption curve. :-) Save the code
breaking for PHP 6.
- Introduce mysqlind library into core and use it as a backend for
PDO and mysqli extensions (possibly enabling them by default)
0
I have not tested it personally, but I'm all for stuff getting faster. I
would recommend making it a simple toggle with default no for now, until it's
more battle-tested in the field. Change the default in 5.4, perhaps.
- OpenID enabling patch for OpenSSL and PHP 5
I have no opinion.
- Add array_replace[_recursive] functions (patch is already available)
1 0 -1
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
1
- Merge the zend_arg_info const'ify patch
I have no opinion.
- Merge the GCC 4 -fvisibility patch
I am not qualified to offer an intelligent opinion.
- Switch for disabling/enabling materialized cursors in mysqli
I have no opinion.
- Link phar extension from PECL into core (possibly enabling it by
default)
I have no opinion.
- Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
I am not qualified to offer an intelligent opinion.
- Introduce new php.ini files parser/scanner + CGI/FastCGI?
"htaccess" style ini file support
I have no opinion.
- Merge __callStatic patch from PHP 6
1
- Introduce concept of "strict classes" that do not permit dynamic
property creation
0
I think I missed that discussion, so I can't say anything useful here other
than please make such classes optional, not required (or inherent upon using
E_STRICT).
--
Larry Garfield AIM: LOLG42
larry@garfieldtech.com ICQ: 6817012
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it." -- Thomas
Jefferson
Its been about a week since RFS for features to go into 5.3 has gone
out and while there was not a "flood" of ideas there is a substantial
list of key changes people would like to go into this release. I've
compiled a list of all of the suggestions I've received, they are
listed below in a form that will hopefully make it easy for people to
vote their yeys and nays. My hope that we can reach an agreement
within 1-2 weeks so 5.3 can be branched and work on it can begin.List of Feature Ideas
- Backport the namespaces patch for PHP 6
1 0 -1
1
- Symlink the intl extension from PECL, but leave it disabled by
default as is the case with all extensions dependent on external libs1 0 -1
Too early, we don't even have a release now. If it is stable by the
end of the year (before RC1), then +1.
- Apply the Late Static Binding Patch
1 0 -1
1
- Implement David's Circular Garbage collection patch
1 0 -1
0
- Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)1 0 -1
+1
- Remove safe_mode, register_globals and magic_quotes
1 0 -1
- Introduce mysqlind library into core and use it as a backend for
PDO and mysqli extensions (possibly enabling them by default)1 0 -1
optional not by default.
- OpenID enabling patch for OpenSSL and PHP 5
1 0 -1
+1 (there is nothing to vote on btw...)
- Add array_replace[_recursive] functions (patch is already available)
1 0 -1
+1
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
1 0 -1
+1
- Merge the zend_arg_info const'ify patch
1 0 -1
+1
- Merge the GCC 4 -fvisibility patch
1 0 -1
0
- Switch for disabling/enabling materialized cursors in mysqli
1 0 -1
0
- Link phar extension from PECL into core (possibly enabling it by
default)1 0 -1
-1
- Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
1 0 -1
1
- Introduce new php.ini files parser/scanner + CGI/FastCGI?
"htaccess" style ini file support1 0 -1
+1, for the record, it allows what htscanner does
(http://pecl.php.net/htscanner) but adding a tons of good things. More
to come very soon, docs from me and patch from Jani.
- Merge __callStatic patch from PHP 6
1 0 -1
1
- Introduce concept of "strict classes" that do not permit dynamic
property creation1 0 -1
1
--Pierre
Ilia Alshanetsky wrote:
Its been about a week since RFS for features to go into 5.3 has gone out
and while there was not a "flood" of ideas there is a substantial list
of key changes people would like to go into this release. I've compiled
a list of all of the suggestions I've received, they are listed below in
a form that will hopefully make it easy for people to vote their yeys
and nays. My hope that we can reach an agreement within 1-2 weeks so 5.3
can be branched and work on it can begin.List of Feature Ideas
- Backport the namespaces patch for PHP 6
+1
- Symlink the intl extension from PECL, but leave it disabled by
default as is the case with all extensions dependent on external libs
0
- Apply the Late Static Binding Patch
+1
- Implement David's Circular Garbage collection patch
0
- Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)
+1
- Remove safe_mode, register_globals and magic_quotes
0
- Introduce mysqlind library into core and use it as a backend for PDO
and mysqli extensions (possibly enabling them by default)
+2
- OpenID enabling patch for OpenSSL and PHP 5
+1
- Add array_replace[_recursive] functions (patch is already available)
+0
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
+100000
- Merge the zend_arg_info const'ify patch
0
- Merge the GCC 4 -fvisibility patch
0
- Switch for disabling/enabling materialized cursors in mysqli
0
- Link phar extension from PECL into core (possibly enabling it by
default)
+1 (by the way, callgrind profiling reveals a ~300% speed difference
between userland PHP_Archive and pecl/phar in average case, and more in
best case. More optimizations are possible and planned as well that
will make phar equal to or even faster than straight FS ops when coupled
with APC).
- Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
0
- Introduce new php.ini files parser/scanner + CGI/FastCGI? "htaccess"
style ini file support
+1
- Merge __callStatic patch from PHP 6
+1
- Introduce concept of "strict classes" that do not permit dynamic
property creation
-1
Thanks,
Greg
Its been about a week since RFS for features to go into 5.3 has gone
out and while there was not a "flood" of ideas there is a substantial
list of key changes people would like to go into this release. I've
compiled a list of all of the suggestions I've received, they are
listed below in a form that will hopefully make it easy for people to
vote their yeys and nays. My hope that we can reach an agreement
within 1-2 weeks so 5.3 can be branched and work on it can begin.List of Feature Ideas
- Backport the namespaces patch for PHP 6
1 0 -1
1
- Symlink the intl extension from PECL, but leave it disabled by
default as is the case with all extensions dependent on external libs1 0 -1
0
- Apply the Late Static Binding Patch
1 0 -1
1
- Implement David's Circular Garbage collection patch
1 0 -1
-1
This is a big change and would probably have to be in PHP6 unless it's
extensively tested on production environment. If it's the case, then
I'm all up for it.
- Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)1 0 -1
1
- Remove safe_mode, register_globals and magic_quotes
1 0 -1
-1
I am scared of the HUGE BC break this is gonna be causing. I really do
hate those parameters and make all my customers not use it, however,
some people still sadly use it.
- Introduce mysqlind library into core and use it as a backend for
PDO and mysqli extensions (possibly enabling them by default)1 0 -1
1
Not by default, --enable-mysqlnd
- OpenID enabling patch for OpenSSL and PHP 5
1 0 -1
1
- Add array_replace[_recursive] functions (patch is already available)
1 0 -1
1
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
1 0 -1
1 YES!
- Merge the zend_arg_info const'ify patch
1 0 -1
1
- Merge the GCC 4 -fvisibility patch
1 0 -1
0
- Switch for disabling/enabling materialized cursors in mysqli
1 0 -1
1
- Link phar extension from PECL into core (possibly enabling it by
default)1 0 -1
1
- Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
1 0 -1
1
- Introduce new php.ini files parser/scanner + CGI/FastCGI?
"htaccess" style ini file support1 0 -1
0
- Merge __callStatic patch from PHP 6
1 0 -1
1
- Introduce concept of "strict classes" that do not permit dynamic
property creation1 0 -1
1
Ilia Alshanetsky
--
One question remains, has SPL been ignored? Forgotten? or just refused?
--
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18
Ilia Alshanetsky wrote:
Its been about a week since RFS for features to go into 5.3 has gone out
and while there was not a "flood" of ideas there is a substantial list
of key changes people would like to go into this release. I've compiled
a list of all of the suggestions I've received, they are listed below in
a form that will hopefully make it easy for people to vote their yeys
and nays. My hope that we can reach an agreement within 1-2 weeks so 5.3
can be branched and work on it can begin.List of Feature Ideas
- Remove safe_mode, register_globals and magic_quotes
PHP6 ONLY
Lets not have another round of broken systems when just upgrading a minor version.
- Introduce mysqlind library into core and use it as a backend for PDO
and mysqli extensions (possibly enabling them by default)
? - Would they get in the way if you are NOT using PDO or mysqli
Why force us to load something that is not generally used by everyone?
In general PERSONALLY I would rather PHP5.3 was bug fixes rather than
distracting from getting PHP6 out of the door?
--
Lester Caine - G8HFL
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird - http://www.firebirdsql.org/index.php
- Backport the namespaces patch for PHP 6
- Symlink the intl extension from PECL, but leave it disabled by
default as is the case with all extensions dependent on external libs
I haven't looked at it yet.
- Apply the Late Static Binding Patch
+0
- Implement David's Circular Garbage collection patch
+1
- Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)
+1
- Remove safe_mode, register_globals and magic_quotes
-1
- Introduce mysqlind library into core and use it as a backend for
PDO and mysqli extensions (possibly enabling them by default)
+1, but maybe not by default yet
- OpenID enabling patch for OpenSSL and PHP 5
+1
- Add array_replace[_recursive] functions (patch is already available)
+0
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
+0
- Merge the zend_arg_info const'ify patch
+1 (biased)
- Merge the GCC 4 -fvisibility patch
+1 (biased)
- Switch for disabling/enabling materialized cursors in mysqli
- Link phar extension from PECL into core (possibly enabling it by default)
0, but not by default.
- Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
+1
The patch is pretty simple. it just needs some typedefs to work on windows.
- Introduce new php.ini files parser/scanner + CGI/FastCGI?
"htaccess" style ini file support
+1, but with the option to disable it.
- Merge __callStatic patch from PHP 6
- Introduce concept of "strict classes" that do not permit dynamic
property creation
-0
Nuno
Its been about a week since RFS for features to go into 5.3 has gone
out and while there was not a "flood" of ideas there is a substantial
list of key changes people would like to go into this release. I've
compiled a list of all of the suggestions I've received, they are
listed below in a form that will hopefully make it easy for people to
vote their yeys and nays. My hope that we can reach an agreement
within 1-2 weeks so 5.3 can be branched and work on it can begin.List of Feature Ideas
- Backport the namespaces patch for PHP 6
1 0 -1
I thought most of us agreed that 5.3 should be == (PHP6 - Unicode).
1
- Symlink the intl extension from PECL, but leave it disabled by
default as is the case with all extensions dependent on external libs1 0 -1
Once it's ready for production - why not?
1
- Apply the Late Static Binding Patch
1 0 -1
0
- Implement David's Circular Garbage collection patch
1 0 -1
IIRC that's one of the reasons for 5.3 branch.
1
- Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)1 0 -1
0/-1 (see on reason to touch a working extension, but I don't really care).
- Remove safe_mode, register_globals and magic_quotes
1 0 -1
Let's leave this for HEAD.
-1
- Introduce mysqlind library into core and use it as a backend for
PDO and mysqli extensions (possibly enabling them by default)1 0 -1
1
Same as PECL/intl - once it's ready, I see no reason to keep it "hidden".
- OpenID enabling patch for OpenSSL and PHP 5
1 0 -1
0
- Add array_replace[_recursive] functions (patch is already available)
1 0 -1
Do we really need more array functions?
I believe we already have quite a number.
-1
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
1 0 -1
-1
Didn't see any arguments for this.
- Merge the zend_arg_info const'ify patch
1 0 -1
0
- Merge the GCC 4 -fvisibility patch
1 0 -1
0
- Switch for disabling/enabling materialized cursors in mysqli
1 0 -1
0
- Link phar extension from PECL into core (possibly enabling it by
default)1 0 -1
0 (-1 for enabling it by default).
- Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
1 0 -1
From what I recall, all Matt's patches were really good.
So I'm 0/+1.
- Introduce new php.ini files parser/scanner + CGI/FastCGI?
"htaccess" style ini file support1 0 -1
0
AFAIK it's too early.
- Merge __callStatic patch from PHP 6
1 0 -1
1/0.
I believe we should decide on more general problems first,
i.e. what is 5_3 - is this (5_2 + a couple of patches) or (HEAD - Unicode)?
- Introduce concept of "strict classes" that do not permit dynamic
property creation1 0 -1
0
--
Wbr,
Antony Dovgal
Its been about a week since RFS for features to go into 5.3 has gone
out and while there was not a "flood" of ideas there is a substantial
list of key changes people would like to go into this release. I've
compiled a list of all of the suggestions I've received, they are
listed below in a form that will hopefully make it easy for people to
vote their yeys and nays. My hope that we can reach an agreement
within 1-2 weeks so 5.3 can be branched and work on it can begin.List of Feature Ideas
- Backport the namespaces patch for PHP 6
1 0 -1
I thought most of us agreed that 5.3 should be == (PHP6 - Unicode).
1
- Symlink the intl extension from PECL, but leave it disabled by
default as is the case with all extensions dependent on external libs1 0 -1
Once it's ready for production - why not?
1
- Apply the Late Static Binding Patch
1 0 -1
0
- Implement David's Circular Garbage collection patch
1 0 -1
IIRC that's one of the reasons for 5.3 branch.
1
- Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)1 0 -1
0/-1 (see on reason to touch a working extension, but I don't really care).
- Remove safe_mode, register_globals and magic_quotes
1 0 -1
Let's leave this for HEAD.
-1
- Introduce mysqlind library into core and use it as a backend for
PDO and mysqli extensions (possibly enabling them by default)1 0 -1
1
Same as PECL/intl - once it's ready, I see no reason to keep it "hidden".
- OpenID enabling patch for OpenSSL and PHP 5
1 0 -1
0
- Add array_replace[_recursive] functions (patch is already available)
1 0 -1
Do we really need more array functions?
I believe we already have quite a number.
-1
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
1 0 -1
-1
Didn't see any arguments for this.
http://marc.info/?l=php-dev&m=116163053224532&w=2
- Merge the zend_arg_info const'ify patch
1 0 -1
0
- Merge the GCC 4 -fvisibility patch
1 0 -1
0
- Switch for disabling/enabling materialized cursors in mysqli
1 0 -1
0
- Link phar extension from PECL into core (possibly enabling it by
default)1 0 -1
0 (-1 for enabling it by default).
- Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
1 0 -1
From what I recall, all Matt's patches were really good.
So I'm 0/+1.
- Introduce new php.ini files parser/scanner + CGI/FastCGI?
"htaccess" style ini file support1 0 -1
0
AFAIK it's too early.
- Merge __callStatic patch from PHP 6
1 0 -1
1/0.
I believe we should decide on more general problems first,
i.e. what is 5_3 - is this (5_2 + a couple of patches) or (HEAD - Unicode)?
Good point
- Introduce concept of "strict classes" that do not permit dynamic
property creation1 0 -1
0
--
Wbr,
Antony Dovgal--
--
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18
All none listed are zero for me.
- Backport the namespaces patch for PHP 6
1
- Remove safe_mode, register_globals and magic_quotes
-1
- Introduce mysqlind library into core and use it as a backend for PDO
and mysqli extensions (possibly enabling them by default)
1
- OpenID enabling patch for OpenSSL and PHP 5
1
- Add array_replace[_recursive] functions (patch is already available)
1
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
1
- Introduce new php.ini files parser/scanner + CGI/FastCGI? "htaccess"
style ini file support
1
--
Brian Moon
Senior Developer
http://dealnews.com/
It's good to be cheap =)
- Backport the namespaces patch for PHP 6
1 as soon as we have it stabilized.
- Symlink the intl extension from PECL, but leave it disabled by
default as is the case with all extensions dependent on external libs
1
- Apply the Late Static Binding Patch
1
- Implement David's Circular Garbage collection patch
Only if no significant performance degradation or one could turn it
on/off at will.
- Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)
1
- Remove safe_mode, register_globals and magic_quotes
-1 I think it's still too early. If we have E_DEPCRECATED however we
might add some annoyances to them ;)
- Introduce mysqlind library into core and use it as a backend for PDO
and mysqli extensions (possibly enabling them by default)
Introduce - +1, use as default - not sure, does mysqlnd has any
downsides? If not, +1 too.
- OpenID enabling patch for OpenSSL and PHP 5
1
- Add array_replace[_recursive] functions (patch is already available)
0
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
- Why do we need it again?
- Merge the zend_arg_info const'ify patch
1
- Merge the GCC 4 -fvisibility patch
1
- Switch for disabling/enabling materialized cursors in mysqli
0
- Link phar extension from PECL into core (possibly enabling it by
default)
-1, we discussed why :) 0 if not enabled by default.
- Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
1
- Introduce new php.ini files parser/scanner + CGI/FastCGI? "htaccess"
style ini file support
- We need to check very thoroughly we won't have security trouble with
it like we had with .htaccess. If it's ok then 1.
- Merge __callStatic patch from PHP 6
1 with all other __static too.
- Introduce concept of "strict classes" that do not permit dynamic
property creation
-1 for now, not sure it's that useful, we are "dynamic" language ;)
I also think the following items are not mentioned:
Dynamic class access ($class::method)
(binary) operator which is the same as (string)
remove --enable-fastcgi and family, always enable them
remove warning for var
Non-parsed heredocs (nowdocs)
goto
__construct in interfaces
Constant folding in compile-time
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stanislav Malyshev wrote:
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
- Why do we need it again?
E_STRICT
is about general coding style that we feel should be
encouraged. Its sort of the comp sci teacher in a box.
E_DEPRECATED
is things we drop are replace. People that need to retain
compatibility to earlier minor versions of PHP will likely have to
ignore these, as often the reason why something was deperecated is that
we added a new shiny alternative that was not there before.
Without it, we mix 2 different concepts, we also make it needlessly hard
for library maintainers to leverage E_STRICT. As a result library
maintainers have the choice of either jumping to every new minor version
as the minimum requirement or more or less ignoring E_STRICT
all together.
regards,
Lukas
Without it, we mix 2 different concepts, we also make it needlessly hard
for library maintainers to leverage E_STRICT. As a result library
maintainers have the choice of either jumping to every new minor version
as the minimum requirement or more or less ignoringE_STRICT
all together.
OK, I understand this, still 0 on it :)
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Lukas Kahwe Smith skrev:
Stanislav Malyshev wrote:
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
- Why do we need it again?
Without it, we mix 2 different concepts, we also make it needlessly hard
for library maintainers to leverage E_STRICT. As a result library
maintainers have the choice of either jumping to every new minor version
as the minimum requirement or more or less ignoringE_STRICT
all together.
Being a teacher who tries to explain PHP daily I am definately +1 on
this one. Separating these two concepts really helps.
Lars Gunther
Hi Ilia,
On Sunday 09 September 2007 07:07:37 pm Ilia Alshanetsky wrote:
List of Feature Ideas
- Backport the namespaces patch for PHP 6
1 0 -1
+1
- Symlink the intl extension from PECL, but leave it disabled by
default as is the case with all extensions dependent on external libs1 0 -1
From what I read that extension offers interesting stuff.
+1
- Apply the Late Static Binding Patch
1 0 -1
0
- Implement David's Circular Garbage collection patch
1 0 -1
I can see the need for this but would like to see the impacts first. Therefore
+0.5
- Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)1 0 -1
I think this would make sense as long as the patch isn't to messy. (I can't
remember seeing it)
+/- 0
- Remove safe_mode, register_globals and magic_quotes
1 0 -1
-1
- Introduce mysqlind library into core and use it as a backend for
PDO and mysqli extensions (possibly enabling them by default)1 0 -1
From what I saw this looks quite good
+1
- OpenID enabling patch for OpenSSL and PHP 5
1 0 -1
+1
- Add array_replace[_recursive] functions (patch is already available)
1 0 -1
I can see some use for these functions but we already have that many array
functions
0
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
1 0 -1
0
- Merge the zend_arg_info const'ify patch
1 0 -1
+1
- Merge the GCC 4 -fvisibility patch
1 0 -1
0
- Switch for disabling/enabling materialized cursors in mysqli
1 0 -1
0
- Link phar extension from PECL into core (possibly enabling it by
default)1 0 -1
+1
- Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
1 0 -1
+1
- Introduce new php.ini files parser/scanner + CGI/FastCGI?
"htaccess" style ini file support1 0 -1
the ini parsing is a fundamental part of PHP therefore we should really test
that stuff to catch as many edge-cases as possible but if we test it well:
+1
- Merge __callStatic patch from PHP 6
1 0 -1
+1
- Introduce concept of "strict classes" that do not permit dynamic
property creation1 0 -1
0
johannes
--
Johannes Schlüter
http://schlueters.de
Its been about a week since RFS for features to go into 5.3 has
gone out and while there was not a "flood" of ideas there is a
substantial list of key changes people would like to go into this
release. I've compiled a list of all of the suggestions I've
received, they are listed below in a form that will hopefully make
it easy for people to vote their yeys and nays. My hope that we can
reach an agreement within 1-2 weeks so 5.3 can be branched and work
on it can begin.List of Feature Ideas
- Backport the namespaces patch for PHP 6
1 0 -1
+1
- Symlink the intl extension from PECL, but leave it disabled by
default as is the case with all extensions dependent on external libs1 0 -1
+1, this will be useful for many people but it would need to make a
lot of progress in a short period of time at least before RC1.
- Apply the Late Static Binding Patch
1 0 -1
+1
- Implement David's Circular Garbage collection patch
1 0 -1
0, I see no problem in adding it but making it an option would be
desirable depending on the overhead.
- Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)1 0 -1
+1, Is this the email I sent you regarding SQLite3? As what I sent
was a new extension that re-implemented everything as OO, I intend to
add it to PECL shortly once I've finished a few more things. The API
for SQLite has changed so much since version 2 that it would require
a lot of re-engineering to keep it backwards compatible. The
extension I have is bundled with 3.4.2 but works with the new 3.5.0
alpha already, I've been using it internally for the past few weeks
without problem, mainly for the extension support in SQLite3.
- Remove safe_mode, register_globals and magic_quotes
1 0 -1
+1, The sooner we get rid of this the better, though I could see
things going wrong if its not properly documented for everyone. I'd
perhaps not remove the functions such as get_magic_quotes_gpc and the
likes and just have them acting like they are disabled. This would
prevent bc breaks for most applications.
- Introduce mysqlind library into core and use it as a backend for
PDO and mysqli extensions (possibly enabling them by default)1 0 -1
+1
- OpenID enabling patch for OpenSSL and PHP 5
1 0 -1
0
- Add array_replace[_recursive] functions (patch is already
available)1 0 -1
0
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
1 0 -1
+1
- Merge the zend_arg_info const'ify patch
1 0 -1
+1
- Merge the GCC 4 -fvisibility patch
1 0 -1
0
- Switch for disabling/enabling materialized cursors in mysqli
1 0 -1
0
- Link phar extension from PECL into core (possibly enabling it
by default)1 0 -1
-1
- Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
1 0 -1
+1
- Introduce new php.ini files parser/scanner + CGI/FastCGI?
"htaccess" style ini file support1 0 -1
+1
- Merge __callStatic patch from PHP 6
1 0 -1
+1
- Introduce concept of "strict classes" that do not permit
dynamic property creation1 0 -1
+1
Scott
Scott MacVicar wrote:
- Remove safe_mode, register_globals and magic_quotes
1 0 -1
+1, The sooner we get rid of this the better, though I could see things
going wrong if its not properly documented for everyone. I'd perhaps not
remove the functions such as get_magic_quotes_gpc and the likes and just
have them acting like they are disabled. This would prevent bc breaks
for most applications.
Don't forget that the majority of users have yet to move FROM PHP4. So making
things even more difficult to port over is not a good idea.
I have two legacy sections of code that I STILL have not worked out what is
stopping me switching off register_globals - code that I inherited from others.
--
Lester Caine - G8HFL
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird - http://www.firebirdsql.org/index.php
Scott MacVicar wrote:
- Remove safe_mode, register_globals and magic_quotes
1 0 -1
+1, The sooner we get rid of this the better, though I could see things
going wrong if its not properly documented for everyone. I'd perhaps not
remove the functions such as get_magic_quotes_gpc and the likes and just
have them acting like they are disabled. This would prevent bc breaks
for most applications.Don't forget that the majority of users have yet to move FROM PHP4. So
making things even more difficult to port over is not a good idea.
I have two legacy sections of code that I STILL have not worked out what is
stopping me switching off register_globals - code that I inherited from
others.
The correct time to break BC is PHP 6. Shared hosts, what most PHP code ends
up running on, are very conservative by nature. They won't upgrade to
something that has any chance of breaking their customers' code unless they
really have to. That means the best way to encourage adoption of new PHP
versions is to save up BC breaks and do them all at once, so that there's
only one "speed bump" to get over instead of several. Such big-BC-breaks are
known in most circles as "major versions". :-)
However, those settings seem like a text-book case where E_DEPRECATED
would be
desirable, as it gives everyone explicit fair warning that those mis-features
are going away soon. That should help PHP 6 adoption in the long run rather
than hinder it.
--
Larry Garfield AIM: LOLG42
larry@garfieldtech.com ICQ: 6817012
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it." -- Thomas
Jefferson
Scott MacVicar wrote:
- Remove safe_mode, register_globals and magic_quotes
1 0 -1
+1, The sooner we get rid of this the better, though I could see things
going wrong if its not properly documented for everyone. I'd perhaps not
remove the functions such as get_magic_quotes_gpc and the likes and just
have them acting like they are disabled. This would prevent bc breaks
for most applications.Don't forget that the majority of users have yet to move FROM PHP4. So
making things even more difficult to port over is not a good idea.
I have two legacy sections of code that I STILL have not worked out what is
stopping me switching off register_globals - code that I inherited from
others.The correct time to break BC is PHP 6. Shared hosts, what most PHP code ends
Please don't use this thread to discuss such problems, it is a vote
only thread. Besides a small comment to explain your vote, there is no
need to start again endless discussions here.
Thanks for your understandings,
--Pierre
Comments inline
Its been about a week since RFS for features to go into 5.3 has gone
out and while there was not a "flood" of ideas there is a substantial
list of key changes people would like to go into this release. I've
compiled a list of all of the suggestions I've received, they are
listed below in a form that will hopefully make it easy for people to
vote their yeys and nays. My hope that we can reach an agreement
within 1-2 weeks so 5.3 can be branched and work on it can begin.List of Feature Ideas
- Backport the namespaces patch for PHP 6
1 0 -1
1
- Symlink the intl extension from PECL, but leave it disabled by
default as is the case with all extensions dependent on external libs1 0 -1
0
- Apply the Late Static Binding Patch
1 0 -1
0
- Implement David's Circular Garbage collection patch
1 0 -1
1
- Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)1 0 -1
1, but should be anything newer than sqlite-3.4.0. Versions prior to
that had some issues with concurrency and locking under extreme load
- Remove safe_mode, register_globals and magic_quotes
1 0 -1
0
- Introduce mysqlind library into core and use it as a backend for
PDO and mysqli extensions (possibly enabling them by default)1 0 -1
1
- OpenID enabling patch for OpenSSL and PHP 5
1 0 -1
1
- Add array_replace[_recursive] functions (patch is already available)
1 0 -1
0
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
1 0 -1
1
- Merge the zend_arg_info const'ify patch
1 0 -1
0
- Merge the GCC 4 -fvisibility patch
1 0 -1
0
- Switch for disabling/enabling materialized cursors in mysqli
1 0 -1
0
- Link phar extension from PECL into core (possibly enabling it by
default)1 0 -1
1
- Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
1 0 -1
1
- Introduce new php.ini files parser/scanner + CGI/FastCGI?
"htaccess" style ini file support1 0 -1
1
- Merge __callStatic patch from PHP 6
1 0 -1
0
- Introduce concept of "strict classes" that do not permit dynamic
property creation1 0 -1
1, if you can disable it to have dynamic property creation (a great
feature of PHP in my opinion)
Ilia Alshanetsky
Ilia Alshanetsky wrote:
Its been about a week since RFS for features to go into 5.3 has gone out
and while there was not a "flood" of ideas there is a substantial list
of key changes people would like to go into this release. I've compiled
a list of all of the suggestions I've received, they are listed below in
a form that will hopefully make it easy for people to vote their yeys
and nays. My hope that we can reach an agreement within 1-2 weeks so 5.3
can be branched and work on it can begin.List of Feature Ideas
- Backport the namespaces patch for PHP 6
1 0 -1
+1
- Symlink the intl extension from PECL, but leave it disabled by
default as is the case with all extensions dependent on external libs1 0 -1
0
- Apply the Late Static Binding Patch
1 0 -1
+1
- Implement David's Circular Garbage collection patch
1 0 -1
0
- Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)1 0 -1
+1
- Remove safe_mode, register_globals and magic_quotes
1 0 -1
-2
- Introduce mysqlind library into core and use it as a backend for PDO
and mysqli extensions (possibly enabling them by default)1 0 -1
+1
- OpenID enabling patch for OpenSSL and PHP 5
1 0 -1
0
- Add array_replace[_recursive] functions (patch is already available)
1 0 -1
+1
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
1 0 -1
+1
- Merge the zend_arg_info const'ify patch
1 0 -1
0
- Merge the GCC 4 -fvisibility patch
1 0 -1
0
- Switch for disabling/enabling materialized cursors in mysqli
1 0 -1
+1
- Link phar extension from PECL into core (possibly enabling it by
default)1 0 -1
+1 (Depends how it will cope with namespaces?)
- Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
1 0 -1
0
- Introduce new php.ini files parser/scanner + CGI/FastCGI? "htaccess"
style ini file support1 0 -1
0
- Merge __callStatic patch from PHP 6
1 0 -1
+1
- Introduce concept of "strict classes" that do not permit dynamic
property creation1 0 -1
0
Regards,
Emil Ivanov
emo wrote:
- Link phar extension from PECL into core (possibly enabling it by
default)1 0 -1
+1 (Depends how it will cope with namespaces?)
??
Perhaps you're thinking of different code? pecl/phar is unaffected by
any changes to the PHP language syntax. Its sole purpose is to provide
a virtual filesystem within a single file through the phar stream
wrapper and the Phar object.
Greg
My bad, please ignore the comment.
Thanks Greg.
Regards,
Emil Ivanov
Gregory Beaver wrote:
emo wrote:
- Link phar extension from PECL into core (possibly enabling it by
default)1 0 -1
+1 (Depends how it will cope with namespaces?)??
Perhaps you're thinking of different code? pecl/phar is unaffected by
any changes to the PHP language syntax. Its sole purpose is to provide
a virtual filesystem within a single file through the phar stream
wrapper and the Phar object.Greg
- Backport the namespaces patch for PHP 6
0
- Symlink the intl extension from PECL, but leave it disabled by
default as is the case with all extensions dependent on external libs
1
- Apply the Late Static Binding Patch
1
- Implement David's Circular Garbage collection patch
0
- Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)
0
- Remove safe_mode, register_globals and magic_quotes
0
- Introduce mysqlind library into core and use it as a backend for
PDO and mysqli extensions (possibly enabling them by default)
1 (not by default)
- OpenID enabling patch for OpenSSL and PHP 5
Which one? (from the looks you are refering to Wez's origional) I though
it was already decided a while back that the patch from Dmitry was going in.
- Add array_replace[_recursive] functions (patch is already available)
0
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
0
- Merge the zend_arg_info const'ify patch
1
- Merge the GCC 4 -fvisibility patch
1
Switch for disabling/enabling materialized cursors in mysqli
1Link phar extension from PECL into core (possibly enabling it by
default)
0
- Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
1
- Introduce new php.ini files parser/scanner + CGI/FastCGI?
"htaccess" style ini file support
0
- Merge __callStatic patch from PHP 6
0
- Introduce concept of "strict classes" that do not permit dynamic
property creation
0
Rob
Hi Rob,
- OpenID enabling patch for OpenSSL and PHP 5
Which one? (from the looks you are refering to Wez's origional) I though
it was already decided a while back that the patch from Dmitry was going in.
For what we discussed, Dmitry's version will be applied. It is more complete.
--Pierre
Ilia Alshanetsky wrote:
- Backport the namespaces patch for PHP 6
+1
- Apply the Late Static Binding Patch
+1
- Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)
+1
- Remove safe_mode, register_globals and magic_quotes
-1
- Introduce mysqlind library into core and use it as a backend for PDO
and mysqli extensions (possibly enabling them by default)
+1 (I assume we will make it easily possible to stick with libmysql if
the user so chooses)
- OpenID enabling patch for OpenSSL and PHP 5
+1
- Add array_replace[_recursive] functions (patch is already available)
+1 (I agree we have a ton of array methods already, but particularly
functions that operate recursively over multi dimensional arrays are
best done in C)
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
+1
- Link phar extension from PECL into core (possibly enabling it by
default)
+1
- Introduce new php.ini files parser/scanner + CGI/FastCGI? "htaccess"
style ini file support
+1
- Introduce concept of "strict classes" that do not permit dynamic
property creation
+1 (I would like this to be even more expanded in that non strict
classes would also not be hit with "artificial" fatal errors).
regards,
Lukas
- Backport the namespaces patch for PHP 6
1
- Symlink the intl extension from PECL, but leave it disabled by
default as is the case with all extensions dependent on external libs
0
- Apply the Late Static Binding Patch
1
- Implement David's Circular Garbage collection patch
0
- Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)
0
- Remove safe_mode, register_globals and magic_quotes
1 ( as long we allow old codes to functions )
- Introduce mysqlind library into core and use it as a backend for
PDO and mysqli extensions (possibly enabling them by default)
0
- OpenID enabling patch for OpenSSL and PHP 5
0
- Add array_replace[_recursive] functions (patch is already available)
1
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
1
- Merge the zend_arg_info const'ify patch
0
- Merge the GCC 4 -fvisibility patch
0
- Switch for disabling/enabling materialized cursors in mysqli
0
- Link phar extension from PECL into core (possibly enabling it by
default)
0
- Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
0
- Introduce new php.ini files parser/scanner + CGI/FastCGI?
"htaccess" style ini file support
0
- Merge __callStatic patch from PHP 6
1
- Introduce concept of "strict classes" that do not permit dynamic
property creation
0
Hello Ilia,
Sunday, September 9, 2007, 7:07:37 PM, you wrote:
- Backport the namespaces patch for PHP 6
+1
- Symlink the intl extension from PECL, but leave it disabled by
+1
- Apply the Late Static Binding Patch
+1
- Implement David's Circular Garbage collection patch
+1
- Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)
+1
- Remove safe_mode, register_globals and magic_quotes
remove register_globals only, rest for 6.*
- Introduce mysqlind library into core and use it as a backend for
PDO and mysqli extensions (possibly enabling them by default)
+1
- OpenID enabling patch for OpenSSL and PHP 5
+1
- Add array_replace[_recursive] functions (patch is already available)
+1
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
+1
- Merge the zend_arg_info const'ify patch
+1 (even though it is me who has to do it i guess :-)
- Merge the GCC 4 -fvisibility patch
0
- Switch for disabling/enabling materialized cursors in mysqli
0
- Link phar extension from PECL into core (possibly enabling it by
default)
+1
- Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
+1
- Introduce new php.ini files parser/scanner + CGI/FastCGI?
"htaccess" style ini file support
+1
- Merge __callStatic patch from PHP 6
+1
- Introduce concept of "strict classes" that do not permit dynamic
property creation
0, we could eventually do this via an interface
Best regards,
Marcus
Hello Ilia,
Monday, September 10, 2007, 3:08:57 PM, you wrote:
Hello Ilia,
Sunday, September 9, 2007, 7:07:37 PM, you wrote:
- Remove safe_mode, register_globals and magic_quotes
remove register_globals only, rest for 6.*
Actually we should get E_DEPRECATED
and mark all as deprecated and be done
for 5.3.
Even though I hate globals and hate me for saying this. But it is better to
go with deprecated first. That way we reduce the WTF factor of our users by
finally telling them what is going to change in the future to give them
preparation time.
Best regards,
Marcus
Hi,
Ilia Alshanetsky wrote:
List of Feature Ideas
- Backport the namespaces patch for PHP 6
+1
- Symlink the intl extension from PECL, but leave it disabled by
default as is the case with all extensions dependent on external libs
0
- Apply the Late Static Binding Patch
+1
- Implement David's Circular Garbage collection patch
-1
- Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)
0
- Remove safe_mode, register_globals and magic_quotes
+1
- Introduce mysqlind library into core and use it as a backend for PDO
and mysqli extensions (possibly enabling them by default)
0
- OpenID enabling patch for OpenSSL and PHP 5
0
- Add array_replace[_recursive] functions (patch is already available)
+1
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
+1
- Merge the zend_arg_info const'ify patch
0
- Merge the GCC 4 -fvisibility patch
0
- Switch for disabling/enabling materialized cursors in mysqli
0
- Link phar extension from PECL into core (possibly enabling it by
default)
+1
- Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
0
- Introduce new php.ini files parser/scanner + CGI/FastCGI? "htaccess"
style ini file support
0
- Merge __callStatic patch from PHP 6
+1
- Introduce concept of "strict classes" that do not permit dynamic
property creation
+1
Best regards,
Stephan
See below:
-----Original Message-----
From: Ilia Alshanetsky [mailto:ilia@prohost.org]
Sent: Sunday, September 09, 2007 10:08 AM
To: PHP Developers Mailing List
Subject: [PHP-DEV] PHP 5.3 Suggested Feature ListList of Feature Ideas
- Backport the namespaces patch for PHP 6
1 0 -1
+1 (pending it's stable and complete).
- Symlink the intl extension from PECL, but leave it disabled by
default as is the case with all extensions dependent on external libs1 0 -1
+1
- Apply the Late Static Binding Patch
1 0 -1
+1 (We will do some perf tests on Dmitry's latest patch to make sure the
impact is minimal).
- Implement David's Circular Garbage collection patch
1 0 -1
+1 (depending on tests, perf and maturity we can decide on
optional/experimental/etc...)
- Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)1 0 -1
0
- Remove safe_mode, register_globals and magic_quotes
1 0 -1
-1
- Introduce mysqlind library into core and use it as a backend for
PDO and mysqli extensions (possibly enabling them by default)1 0 -1
0
- OpenID enabling patch for OpenSSL and PHP 5
1 0 -1
+1
- Add array_replace[_recursive] functions (patch is already
available)1 0 -1
+1
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
1 0 -1
+1
- Merge the zend_arg_info const'ify patch
1 0 -1
0
- Merge the GCC 4 -fvisibility patch
1 0 -1
0
- Switch for disabling/enabling materialized cursors in mysqli
1 0 -1
0
- Link phar extension from PECL into core (possibly enabling it by
default)1 0 -1
-1 (I'd prefer a standard format which can be manipulated with standard
tools (also some tests we did with TAR format we got much better
performance). In general though the use-case should be clear as I don't
think Web apps are the real target here))
- Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
1 0 -1
+1
- Introduce new php.ini files parser/scanner + CGI/FastCGI?
"htaccess" style ini file support1 0 -1
0 (this can be nice but we need to make sure it's optional because those
stat()
's can be very hard on performance which is why many sites turn
off .htaccess).
- Merge __callStatic patch from PHP 6
1 0 -1
+1
- Introduce concept of "strict classes" that do not permit dynamic
property creation1 0 -1
-1
See below:
-----Original Message-----
From: Ilia Alshanetsky [mailto:ilia@prohost.org]
Sent: Sunday, September 09, 2007 10:08 AM
To: PHP Developers Mailing List
Subject: [PHP-DEV] PHP 5.3 Suggested Feature ListList of Feature Ideas
- Backport the namespaces patch for PHP 6
1 0 -1
+1 (pending it's stable and complete).
- Symlink the intl extension from PECL, but leave it disabled by
default as is the case with all extensions dependent on external libs1 0 -1
+1
- Apply the Late Static Binding Patch
1 0 -1
+1 (We will do some perf tests on Dmitry's latest patch to make sure the
impact is minimal).
- Implement David's Circular Garbage collection patch
1 0 -1
+1 (depending on tests, perf and maturity we can decide on
optional/experimental/etc...)
- Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)1 0 -1
0
- Remove safe_mode, register_globals and magic_quotes
1 0 -1
-1
- Introduce mysqlind library into core and use it as a backend for
PDO and mysqli extensions (possibly enabling them by default)1 0 -1
0
- OpenID enabling patch for OpenSSL and PHP 5
1 0 -1
+1
- Add array_replace[_recursive] functions (patch is already
available)1 0 -1
+1
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
1 0 -1
+1
- Merge the zend_arg_info const'ify patch
1 0 -1
0
- Merge the GCC 4 -fvisibility patch
1 0 -1
0
- Switch for disabling/enabling materialized cursors in mysqli
1 0 -1
0
- Link phar extension from PECL into core (possibly enabling it by
default)1 0 -1
-1 (I'd prefer a standard format which can be manipulated with standard
tools (also some tests we did with TAR format we got much better
performance). In general though the use-case should be clear as I don't
think Web apps are the real target here))
- Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
1 0 -1
+1
- Introduce new php.ini files parser/scanner + CGI/FastCGI?
"htaccess" style ini file support1 0 -1
0 (this can be nice but we need to make sure it's optional because those
stat()
's can be very hard on performance which is why many sites turn
off .htaccess).
For the record here, a cache is planed once we have a stable version.
Something like what htscanner does, it already caches the entries
(cache + stat check once ttl is over).
Cheers,
--Pierre
-----Original Message-----
From: Pierre [mailto:pierre.php@gmail.com]
Sent: Monday, September 10, 2007 1:56 PM
To: Andi Gutmans
Cc: Ilia Alshanetsky; PHP Developers Mailing List
Subject: Re: [PHP-DEV] PHP 5.3 Suggested Feature ListFor the record here, a cache is planed once we have a stable version.
Something like what htscanner does, it already caches the entries
(cache + stat check once ttl is over).
We've wanted to do a stat()
cache for quite a while. If you work on it,
please make it generic in TSRM and then we can use it in various places
in PHP including this feature.
Thanks!
ANdi
- Introduce new php.ini files parser/scanner + CGI/FastCGI?
"htaccess" style ini file support1 0 -1
0 (this can be nice but we need to make sure it's optional because those
stat()
's can be very hard on performance which is why many sites turn
off .htaccess).For the record here, a cache is planed once we have a stable version.
Something like what htscanner does, it already caches the entries
(cache + stat check once ttl is over).
Just clarification: the caching is there already. :)
But I didn't use any stat calls for sake of KISS.
When cached results expire, the file (if it exists..) is re-scanned.
Maybe someone has better idea. But that remains to be seen. :)
--Jani
--
Patches/Donations: http://pecl.php.net/~jani/
- Introduce new php.ini files parser/scanner + CGI/FastCGI?
"htaccess" style ini file support1 0 -1
0 (this can be nice but we need to make sure it's optional because those
stat()
's can be very hard on performance which is why many sites turn
off .htaccess).For the record here, a cache is planed once we have a stable version.
Something like what htscanner does, it already caches the entries
(cache + stat check once ttl is over).Just clarification: the caching is there already. :)
But I didn't use any stat calls for sake of KISS.
When cached results expire, the file (if it exists..) is re-scanned.
Maybe someone has better idea. But that remains to be seen. :)
Oh damned me, I did not notice it in the patch :)
And I agree, for this feature, a cache system like this one is the
easiest way (to maintain and to keep the performance impact as a very
low level) and works well. I use such system since months with
htscanner (and some ISPs too) and did not notice a significant slow
down.
Cheers,
--Pierre
Andi Gutmans wrote:
- Link phar extension from PECL into core (possibly enabling it by
default)1 0 -1
-1 (I'd prefer a standard format which can be manipulated with standard
tools (also some tests we did with TAR format we got much better
performance). In general though the use-case should be clear as I don't
think Web apps are the real target here))
Care to share how you benchmarked? I found an exponential performance
improvement when I moved from tar to the current file format.
Greg
Yes, I will ask Dmitry to share it with you. There's huge value in
having a standard format which existing tools can already manipulate. It
doesn't have to be tar but IMO it should be something standard.
Andi
-----Original Message-----
From: Gregory Beaver [mailto:greg@chiaraquartet.net]
Sent: Monday, September 10, 2007 2:08 PM
To: Andi Gutmans
Cc: PHP Developers Mailing List
Subject: Re: [PHP-DEV] PHP 5.3 Suggested Feature ListAndi Gutmans wrote:
- Link phar extension from PECL into core (possibly enabling it
by
default)1 0 -1
-1 (I'd prefer a standard format which can be manipulated with
standard
tools (also some tests we did with TAR format we got much better
performance). In general though the use-case should be clear as I
don't
think Web apps are the real target here))Care to share how you benchmarked? I found an exponential performance
improvement when I moved from tar to the current file format.Greg
Yes, I will ask Dmitry to share it with you. There's huge value in
having a standard format which existing tools can already manipulate. It
doesn't have to be tar but IMO it should be something standard.Andi
-----Original Message-----
From: Gregory Beaver [mailto:greg@chiaraquartet.net]
Sent: Monday, September 10, 2007 2:08 PM
To: Andi Gutmans
Cc: PHP Developers Mailing List
Subject: Re: [PHP-DEV] PHP 5.3 Suggested Feature ListAndi Gutmans wrote:
- Link phar extension from PECL into core (possibly enabling it
by
default)1 0 -1
-1 (I'd prefer a standard format which can be manipulated with
standard
tools (also some tests we did with TAR format we got much better
performance). In general though the use-case should be clear as I
don't
think Web apps are the real target here))Care to share how you benchmarked? I found an exponential performance
improvement when I moved from tar to the current file format.Greg
--
Andi, if there was to be a cross platform tool to view, extract, add,
etc with phar archives, would that influence your choice ?
Thanks,
--
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18
-----Original Message-----
From: david.coallier@gmail.com [mailto:david.coallier@gmail.com] On
Behalf Of David Coallier
Sent: Monday, September 10, 2007 4:05 PM
To: Andi Gutmans
Cc: Gregory Beaver; PHP Developers Mailing List
Subject: Re: [PHP-DEV] PHAR was PHP 5.3 Suggested Feature ListAndi, if there was to be a cross platform tool to view, extract, add,
etc with phar archives, would that influence your choice ?
Well the point is that if you're using tar, zip (jar) or some other standard file format you have thousands of tools that you can use.
The format is really mainly an implementation detail (maybe with some minor semantics) so I think it's better for PHP to embrace an existing one than coming up with its own. This is also why Java took this approach.
I realize there is some history to this implementation but I think tweaking the file format part of the implementation isn't a large amount of work and worthwhile in the long run esp. as phar hasn't been widely adopted at this point (and probably won't be for Web apps but rather installations and administration solutions).
Andi
Andi Gutmans wrote:
-----Original Message-----
From: david.coallier@gmail.com [mailto:david.coallier@gmail.com] On
Behalf Of David Coallier
Sent: Monday, September 10, 2007 4:05 PM
To: Andi Gutmans
Cc: Gregory Beaver; PHP Developers Mailing List
Subject: Re: [PHP-DEV] PHAR was PHP 5.3 Suggested Feature ListAndi, if there was to be a cross platform tool to view, extract, add,
etc with phar archives, would that influence your choice ?Well the point is that if you're using tar, zip (jar) or some other standard file format you have thousands of tools that you can use.
The format is really mainly an implementation detail (maybe with some minor semantics) so I think it's better for PHP to embrace an existing one than coming up with its own. This is also why Java took this approach.I realize there is some history to this implementation but I think tweaking the file format part of the implementation isn't a large amount of work and worthwhile in the long run esp. as phar hasn't been widely adopted at this point (and probably won't be for Web apps but rather installations and administration solutions).
Hi,
I'd like to clear up some confusion.
Actually, phar works quite well in a web environment, I suggest we stop
talking about it as if it were just an installation stub. There is even
a possibility that applications within a phar will be faster than their
filesystem equivalent when used with (as yet unwritten changes to) APC
because of the complete lack of a need to do any filesystem stats on the
files.
The implementation of the jar format would require changes to the Zend
Engine in order to work in the way that phar works, as there is no way
to use a PHP loader stub with a jar because it uses the zip file
format. Even if we did go with another standard file format like tar
which the original PHP_Archive class used (A hack can be used to make
the first file into a PHP loader stub), for performance reasons the
structure of the file would still need to be specific to PHP's needs,
rendering all of those thousands of tools useless for anything but
looking inside of the file to see how it was implemented. For instance,
the jar file format is a zip file with a customized manifest stored as
one of the files. The same would be true of a tar-based implementation,
but even more customization would be needed as we would need to store
the index as well, something that is built into the zip file format.
I chose a different file format because it was a better choice both for
performance and usability than the existing formats out there, and
simply calling it "different" does not do justice to the reasons that
make it better. The reason we do not do classes like java is because
PHP is not java, as many are very happy to say and rightly so. Why turn
around and make the same arguments for phar? Phar is not jar any more
than PHP namespace is C++ namespace. It does not solve the same
problems as jar in Java, nor does it intend to solve the same problems.
Incidentally, pecl/phar already provides a cross-platform tool to view,
extract, add, it's called "phar.phar" and is run via "php phar.phar". I
don't think it is quite feature complete, but this would actually take a
small amount of work to reach that point, much less than modifying PHP's
core to support the jar file format.
I am happy to look at other implementations of the file format if and
only if it can be shown to be worth the change, but I do expect the
courtesy of compelling arguments that take into account the work already
completed so that I'm not wasting anyone's time including my own.
Thanks,
Greg
Hi Greg,
I didn't mean to get you all defensive about it. I was just voicing my personal thoughts on this subject as I did a few months back. It's just my 2 cents and you're free to take it or leave it.
I think from a perf point of view the info Dmitry can send you may at least give you some ideas on why we got better results with tar (and no, I am not married to tar. I just thought it'd be nice to use something standard so zip, etc. would be cool too).
Deployment is definitely a question-mark for me. Where can I find more information on deploying a Web app using phar? Am I right to assume that mod_rewrite is part of the equation? How is it done on Windows?
Btw, this isn't about making PHP into Java (which I'm the first to not want to do) nor am I specifically calling out JAR. I'm just saying a standard format would be nice.
And yes, I agree, it'd be nice to not have to make any significant changes in the core for this.
Andi
-----Original Message-----
From: Gregory Beaver [mailto:greg@chiaraquartet.net]
Sent: Monday, September 10, 2007 10:09 PM
To: Andi Gutmans
Cc: David Coallier; PHP Developers Mailing List
Subject: Why not jar for phar? (was Re: [PHP-DEV] PHAR was PHP 5.3
Suggested Feature List)Andi Gutmans wrote:
-----Original Message-----
From: david.coallier@gmail.com [mailto:david.coallier@gmail.com] On
Behalf Of David Coallier
Sent: Monday, September 10, 2007 4:05 PM
To: Andi Gutmans
Cc: Gregory Beaver; PHP Developers Mailing List
Subject: Re: [PHP-DEV] PHAR was PHP 5.3 Suggested Feature ListAndi, if there was to be a cross platform tool to view, extract,
add,
etc with phar archives, would that influence your choice ?Well the point is that if you're using tar, zip (jar) or some other
standard file format you have thousands of tools that you can use.
The format is really mainly an implementation detail (maybe with some
minor semantics) so I think it's better for PHP to embrace an existing
one than coming up with its own. This is also why Java took this
approach.I realize there is some history to this implementation but I think
tweaking the file format part of the implementation isn't a large
amount of work and worthwhile in the long run esp. as phar hasn't been
widely adopted at this point (and probably won't be for Web apps but
rather installations and administration solutions).
Hi,I'd like to clear up some confusion.
Actually, phar works quite well in a web environment, I suggest we stop
talking about it as if it were just an installation stub. There is
even
a possibility that applications within a phar will be faster than their
filesystem equivalent when used with (as yet unwritten changes to) APC
because of the complete lack of a need to do any filesystem stats on
the
files.The implementation of the jar format would require changes to the Zend
Engine in order to work in the way that phar works, as there is no way
to use a PHP loader stub with a jar because it uses the zip file
format. Even if we did go with another standard file format like tar
which the original PHP_Archive class used (A hack can be used to make
the first file into a PHP loader stub), for performance reasons the
structure of the file would still need to be specific to PHP's needs,
rendering all of those thousands of tools useless for anything but
looking inside of the file to see how it was implemented. For
instance,
the jar file format is a zip file with a customized manifest stored as
one of the files. The same would be true of a tar-based
implementation,
but even more customization would be needed as we would need to store
the index as well, something that is built into the zip file format.I chose a different file format because it was a better choice both for
performance and usability than the existing formats out there, and
simply calling it "different" does not do justice to the reasons that
make it better. The reason we do not do classes like java is because
PHP is not java, as many are very happy to say and rightly so. Why
turn
around and make the same arguments for phar? Phar is not jar any more
than PHP namespace is C++ namespace. It does not solve the same
problems as jar in Java, nor does it intend to solve the same problems.Incidentally, pecl/phar already provides a cross-platform tool to view,
extract, add, it's called "phar.phar" and is run via "php phar.phar".
I
don't think it is quite feature complete, but this would actually take
a
small amount of work to reach that point, much less than modifying
PHP's
core to support the jar file format.I am happy to look at other implementations of the file format if and
only if it can be shown to be worth the change, but I do expect the
courtesy of compelling arguments that take into account the work
already
completed so that I'm not wasting anyone's time including my own.Thanks,
Greg
Hello Andi,
to end this 'many tools' reasoning. For those issues we already adopted
zip and if people insist I wouldn't mind if anybody would provide a working
tar implementation that allows reading of tgz and tar.bz2 files as well.
Yest the purpose of Phar is very different. Anyway can it be that Dmitry was
using an old version of Phar where indeed the performance was bad?
marcus
Tuesday, September 11, 2007, 7:40:29 AM, you wrote:
Hi Greg,
I didn't mean to get you all defensive about it. I was just voicing my
personal thoughts on this subject as I did a few months back. It's just my
2 cents and you're free to take it or leave it.
I think from a perf point of view the info Dmitry can send you may at
least give you some ideas on why we got better results with tar (and no, I
am not married to tar. I just thought it'd be nice to use something
standard so zip, etc. would be cool too).
Deployment is definitely a question-mark for me. Where can I find more
information on deploying a Web app using phar? Am I right to assume that
mod_rewrite is part of the equation? How is it done on Windows?
Btw, this isn't about making PHP into Java (which I'm the first to not
want to do) nor am I specifically calling out JAR. I'm just saying a standard format would be nice.
And yes, I agree, it'd be nice to not have to make any significant changes in the core for this.
Andi
-----Original Message-----
From: Gregory Beaver [mailto:greg@chiaraquartet.net]
Sent: Monday, September 10, 2007 10:09 PM
To: Andi Gutmans
Cc: David Coallier; PHP Developers Mailing List
Subject: Why not jar for phar? (was Re: [PHP-DEV] PHAR was PHP 5.3
Suggested Feature List)Andi Gutmans wrote:
-----Original Message-----
From: david.coallier@gmail.com [mailto:david.coallier@gmail.com] On
Behalf Of David Coallier
Sent: Monday, September 10, 2007 4:05 PM
To: Andi Gutmans
Cc: Gregory Beaver; PHP Developers Mailing List
Subject: Re: [PHP-DEV] PHAR was PHP 5.3 Suggested Feature ListAndi, if there was to be a cross platform tool to view, extract,
add,
etc with phar archives, would that influence your choice ?Well the point is that if you're using tar, zip (jar) or some other
standard file format you have thousands of tools that you can use.
The format is really mainly an implementation detail (maybe with some
minor semantics) so I think it's better for PHP to embrace an existing
one than coming up with its own. This is also why Java took this
approach.I realize there is some history to this implementation but I think
tweaking the file format part of the implementation isn't a large
amount of work and worthwhile in the long run esp. as phar hasn't been
widely adopted at this point (and probably won't be for Web apps but
rather installations and administration solutions).
Hi,I'd like to clear up some confusion.
Actually, phar works quite well in a web environment, I suggest we stop
talking about it as if it were just an installation stub. There is
even
a possibility that applications within a phar will be faster than their
filesystem equivalent when used with (as yet unwritten changes to) APC
because of the complete lack of a need to do any filesystem stats on
the
files.The implementation of the jar format would require changes to the Zend
Engine in order to work in the way that phar works, as there is no way
to use a PHP loader stub with a jar because it uses the zip file
format. Even if we did go with another standard file format like tar
which the original PHP_Archive class used (A hack can be used to make
the first file into a PHP loader stub), for performance reasons the
structure of the file would still need to be specific to PHP's needs,
rendering all of those thousands of tools useless for anything but
looking inside of the file to see how it was implemented. For
instance,
the jar file format is a zip file with a customized manifest stored as
one of the files. The same would be true of a tar-based
implementation,
but even more customization would be needed as we would need to store
the index as well, something that is built into the zip file format.I chose a different file format because it was a better choice both for
performance and usability than the existing formats out there, and
simply calling it "different" does not do justice to the reasons that
make it better. The reason we do not do classes like java is because
PHP is not java, as many are very happy to say and rightly so. Why
turn
around and make the same arguments for phar? Phar is not jar any more
than PHP namespace is C++ namespace. It does not solve the same
problems as jar in Java, nor does it intend to solve the same problems.Incidentally, pecl/phar already provides a cross-platform tool to view,
extract, add, it's called "phar.phar" and is run via "php phar.phar".
I
don't think it is quite feature complete, but this would actually take
a
small amount of work to reach that point, much less than modifying
PHP's
core to support the jar file format.I am happy to look at other implementations of the file format if and
only if it can be shown to be worth the change, but I do expect the
courtesy of compelling arguments that take into account the work
already
completed so that I'm not wasting anyone's time including my own.Thanks,
Greg
Best regards,
Marcus
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello Andi,
to end this 'many tools' reasoning. For those issues we already
adopted
zip and if people insist I wouldn't mind if anybody would provide a
working
tar implementation that allows reading of tgz and tar.bz2 files as
well.
Yest the purpose of Phar is very different. Anyway can it be that
Dmitry was
using an old version of Phar where indeed the performance was bad?
While this may seem trivial to some, is there a reason that spl is
disabled when phar is enabled?
marcus
- -- Dale
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
iD8DBQFG5oxg0hzWbkf0eKgRAq03AKDOy7h6XGSg9nZ4C5ZdCCkmu+0dyACdH8VB
4aUIE+OBi0ArJG5W+mYxf2U=
=tWzE
-----END PGP SIGNATURE
BuildSmart wrote:
Hello Andi,
to end this 'many tools' reasoning. For those issues we already
adopted
zip and if people insist I wouldn't mind if anybody would provide a
working
tar implementation that allows reading of tgz and tar.bz2 files as well.
Yest the purpose of Phar is very different. Anyway can it be that
Dmitry was
using an old version of Phar where indeed the performance was bad?While this may seem trivial to some, is there a reason that spl is
disabled when phar is enabled?
It might seem trivial to others because you're not reading the source
correctly. SPL is not disabled when phar is enabled.
Greg
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
BuildSmart wrote:
Hello Andi,
to end this 'many tools' reasoning. For those issues we already
adopted
zip and if people insist I wouldn't mind if anybody would provide a
working
tar implementation that allows reading of tgz and tar.bz2 files
as well.
Yest the purpose of Phar is very different. Anyway can it be that
Dmitry was
using an old version of Phar where indeed the performance was bad?While this may seem trivial to some, is there a reason that spl is
disabled when phar is enabled?It might seem trivial to others because you're not reading the source
correctly. SPL is not disabled when phar is enabled.
doesn't the following mean it's disabled or am I interpreting it wrong?
PHP_ADD_EXTENSION_DEP(phar, spl, false)
Greg
- -- Dale
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
iD8DBQFG5qkX0hzWbkf0eKgRAraRAJ9ZEGTO3iSbqMuls3bjTsbYubBecACgu24O
xi3+5P3vzjWQvILG+9/zwrI=
=UxTD
-----END PGP SIGNATURE
It might seem trivial to others because you're not reading the source
correctly. SPL is not disabled when phar is enabled.doesn't the following mean it's disabled or am I interpreting it wrong?
PHP_ADD_EXTENSION_DEP(phar, spl, false)
nope. it means, that "phar" depends on "spl" and this dependency is not optional
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
- Introduce new php.ini files parser/scanner + CGI/FastCGI?
"htaccess" style ini file support1 0 -1
0 (this can be nice but we need to make sure it's optional because those
stat()
's can be very hard on performance which is why many sites turn
off .htaccess).
Already is optional and only is used with sapi/cgi right now.
Also the ".htaccess" results are cached to minimize the performance
penalty. Another thing is that you can put the stuff in the main
php.ini, using the special section stuff I implemented.
Thus you don't need the ".htaccess" files at all if necessary.
IMO, this isn't just "nice", this is essential functionality that should
have been done years ago. But I'm biased. :)
--Jani
--
Patches/Donations: http://pecl.php.net/~jani/
- Merge the GCC 4 -fvisibility patch
That patch is a very good idea, but it does not work there are symbols
that are no lomger exported on libxml extension , and although
everything compiles, I ended with a broken PHP.
That patch is a very good idea, but it does not work there are symbols
that are no lomger exported on libxml extension , and although
everything compiles, I ended with a broken PHP.
Can you give a bit more details on what is broken? Does it mean there's
a problem on Windows too, since Windows doesn't allow accessing
un-exported symbols?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
That patch is a very good idea, but it does not work there are symbols
that are no lomger exported on libxml extension , and although
everything compiles, I ended with a broken PHP.Can you give a bit more details on what is broken? Does it mean there's a
problem on Windows too, since Windows doesn't allow accessing un-exported
symbols?
I'm aware of this problem. The problem is that each extension defines its
own PHP_EXT_API (where EXT is the name of the extension). This means we need
to change every such macro out there to make them aware of gcc 4.
My proposal to avoid future problems is to reuse the PHPAPI macro, as can be
seen in that patch (I only changed the hash extension as an example):
--- ext/hash/php_hash.h 16 Jan 2006 23:04:23 -0000 1.13.2.7
+++ ext/hash/php_hash.h 9 Nov 2006 16:50:55 -0000
(...)
-#ifdef PHP_WIN32
-#define PHP_HASH_API __declspec(dllexport)
-#else
-#define PHP_HASH_API
-#endif
+#define PHP_HASH_API PHPAPI
When the patch goes in, I'll change all that stuff.
Nuno
Ilia Alshanetsky wrote:
List of Feature Ideas
- Backport the namespaces patch for PHP 6
-1
- Symlink the intl extension from PECL, but leave it disabled by
default as is the case with all extensions dependent on external libs
1
- Apply the Late Static Binding Patch
1 0 -1
1
- Implement David's Circular Garbage collection patch
-1
- Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)
1
- Remove safe_mode, register_globals and magic_quotes
-1
- Introduce mysqlind library into core and use it as a backend for PDO
and mysqli extensions (possibly enabling them by default)
0
- OpenID enabling patch for OpenSSL and PHP 5
1
- Add array_replace[_recursive] functions (patch is already available)
1
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
1
- Merge the zend_arg_info const'ify patch
1
- Merge the GCC 4 -fvisibility patch
1
- Switch for disabling/enabling materialized cursors in mysqli
0
- Link phar extension from PECL into core (possibly enabling it by
default)
1
- Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
1
- Introduce new php.ini files parser/scanner + CGI/FastCGI? "htaccess"
style ini file support
0
- Merge __callStatic patch from PHP 6
0
- Introduce concept of "strict classes" that do not permit dynamic
property creation
Good idea, but I'd leave it for PHP 6.
-Andrei
http://10fathoms.org/vu - daily photoblog
Ilia Alshanetsky wrote:
- Backport the namespaces patch for PHP 6
0
- Symlink the intl extension from PECL, but leave it disabled by
default as is the case with all extensions dependent on external libs
0
- Apply the Late Static Binding Patch
1
- Implement David's Circular Garbage collection patch
1
- Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)
0
- Remove safe_mode, register_globals and magic_quotes
0
- Introduce mysqlind library into core and use it as a backend for PDO
and mysqli extensions (possibly enabling them by default)
1
- OpenID enabling patch for OpenSSL and PHP 5
1
- Add array_replace[_recursive] functions (patch is already available)
1
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
1
- Merge the zend_arg_info const'ify patch
1
- Merge the GCC 4 -fvisibility patch
1
- Switch for disabling/enabling materialized cursors in mysqli
0
- Link phar extension from PECL into core (possibly enabling it by
default)
0
- Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
0
- Introduce new php.ini files parser/scanner + CGI/FastCGI? "htaccess"
style ini file support
0
- Merge __callStatic patch from PHP 6
1
- Introduce concept of "strict classes" that do not permit dynamic
property creation
1
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
- Backport the namespaces patch for PHP 6
+1
- Apply the Late Static Binding Patch
+1
- Remove safe_mode, register_globals and magic_quotes
-1
- OpenID enabling patch for OpenSSL and PHP 5
+1
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
+1
- Merge the zend_arg_info const'ify patch
+1
- Link phar extension from PECL into core (possibly enabling it by
default)
+1
BTW, I would prefer something more toolable (like TAR or ZIP)
- Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
+1
- Merge __callStatic patch from PHP 6
+1
- Introduce concept of "strict classes" that do not permit dynamic
property creation
-1
Thanks. Dmitry.
Ilia Alshanetsky wrote:
- Backport the namespaces patch for PHP 6
+1
- Symlink the intl extension from PECL, but leave it disabled by
default as is the case with all extensions dependent on external libs
0 (didn't see anything relevant of it yet)
- Apply the Late Static Binding Patch
+1
- Implement David's Circular Garbage collection patch
0 (is this really something for a minor version?)
- Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)
0
- Remove safe_mode, register_globals and magic_quotes
-1 (never used any, but I'd say leave that items up for the next major)
- Introduce mysqlind library into core and use it as a backend for PDO
and mysqli extensions (possibly enabling them by default)
+1 (if it's considered stable enough)
- OpenID enabling patch for OpenSSL and PHP 5
+1
- Add array_replace[_recursive] functions (patch is already available)
0
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
+1
- Merge the zend_arg_info const'ify patch
+1
- Merge the GCC 4 -fvisibility patch
-1 (eventually make it a configure option first? PHP is a API mess)
- Switch for disabling/enabling materialized cursors in mysqli
0
- Link phar extension from PECL into core (possibly enabling it by
default)
+1
- Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
+1
- Introduce new php.ini files parser/scanner + CGI/FastCGI? "htaccess"
style ini file support
+1
- Merge __callStatic patch from PHP 6
+1
- Introduce concept of "strict classes" that do not permit dynamic
property creation
+1
Regards,
Michael
- Merge the GCC 4 -fvisibility patch
-1 (eventually make it a configure option first? PHP is a API mess)
The patch is safe because otherwise PHP wouldn't work on windows (as windows
doesn't export the symbols by default).
Nuno
- Backport the namespaces patch for PHP 6
1
- Symlink the intl extension from PECL, but leave it disabled by
default as is the case with all extensions dependent on external libs
1
- Apply the Late Static Binding Patch
1
- Implement David's Circular Garbage collection patch
0
- Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)
1
- Remove safe_mode, register_globals and magic_quotes
-1, and only RG has had appropriate warning/info thus far.
- Introduce mysqlind library into core and use it as a backend for
PDO and mysqli extensions (possibly enabling them by default)
1
- OpenID enabling patch for OpenSSL and PHP 5
1
- Add array_replace[_recursive] functions (patch is already
available)
1
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
1
- Merge the zend_arg_info const'ify patch
1
- Merge the GCC 4 -fvisibility patch
1
- Switch for disabling/enabling materialized cursors in mysqli
0
- Link phar extension from PECL into core (possibly enabling it
by default)
0
- Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
0
- Introduce new php.ini files parser/scanner + CGI/FastCGI?
"htaccess" style ini file support
1
- Merge __callStatic patch from PHP 6
1
- Introduce concept of "strict classes" that do not permit
dynamic property creation
-1 E_FATAL, +1 E_STRICT
Regards,
Philip
If it counts for anything, here's my vote on the bits I know/care about:
- Symlink the intl extension from PECL, but leave it disabled by default
as is the case with all extensions dependent on external libs
+1, I've a feeling this will become important later
- Apply the Late Static Binding Patch
+1, I'll probably never use it but I can see where others might
- Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)
+1, assuming this won't kill sqlite2 support (where's the patch?)
- Remove safe_mode, register_globals and magic_quotes
-1, should be on a major release - but as someone (Stas?) wrote earlier, it
might be a good time to start emitting deprecation warnings
- Introduce mysqlind library into core and use it as a backend for PDO
and mysqli extensions (possibly enabling them by default)
+1 but nothing by default until stable
- OpenID enabling patch for OpenSSL and PHP 5
+1, is there even an argument against this?
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
+1, about time!
- Link phar extension from PECL into core (possibly enabling it by
default)
+1, I think this could help tremendously with application deployment
- Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
+1, we all love Matt
- Introduce new php.ini files parser/scanner + CGI/FastCGI? "htaccess"
style ini file support
0 - very torn over this idea
- Merge __callStatic patch from PHP 6
+1
- Introduce concept of "strict classes" that do not permit dynamic
property creation
-1, this whole idea just sounds so weird for PHP.
- Steph
Steph Fox wrote:
- Introduce concept of "strict classes" that do not permit dynamic
property creation-1, this whole idea just sounds so weird for PHP.
Sure, but how PHPish is this fatal error?
mike@honeybadger:~/build/php-5.2-debug$ cli -r 'class c{} c::$x=1;'
Fatal error: Access to undeclared static property: c::$x in Command
line code on line 1
The idea, as far as I understood, was to allow this things with
non-strict classes once we have strict classes.
Regards,
Michael
Heya Mike,
-1, this whole idea just sounds so weird for PHP.
Sure, but how PHPish is this fatal error?
mike@honeybadger:~/build/php-5.2-debug$ cli -r 'class c{} c::$x=1;'
Fatal error: Access to undeclared static property: c::$x in Command
line code on line 1The idea, as far as I understood, was to allow this things with
non-strict classes once we have strict classes.
Nothing like telling it backwards, mm?
OK, for some reason I was under the impression that that behaviour had been
reverted and this was an attempt to put it back in <sigh />
Make that a +1 for exactly the same reason it was a -1 before. If it counts,
which it probably doesn't.
- Steph
Am 09.09.2007 um 19:07 schrieb Ilia Alshanetsky:
Its been about a week since RFS for features to go into 5.3 has
gone out and while there was not a "flood" of ideas there is a
substantial list of key changes people would like to go into this
release. I've compiled a list of all of the suggestions I've
received, they are listed below in a form that will hopefully make
it easy for people to vote their yeys and nays. My hope that we can
reach an agreement within 1-2 weeks so 5.3 can be branched and work
on it can begin.List of Feature Ideas
- Backport the namespaces patch for PHP 6
1 0 -1
+1
- Symlink the intl extension from PECL, but leave it disabled by
default as is the case with all extensions dependent on external libs1 0 -1
-1
Wait until it is stable and feature complete (guess it wouldn't be in
time a for a 5.3 release), otherwise, we might run into the problem
that minor releases have different functionalities.
- Apply the Late Static Binding Patch
1 0 -1
+1
- Implement David's Circular Garbage collection patch
1 0 -1
-1
Is that really tested well enough already?
- Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)1 0 -1
0
- Remove safe_mode, register_globals and magic_quotes
1 0 -1
-1
Why break BC in a .x release?
- Introduce mysqlind library into core and use it as a backend for
PDO and mysqli extensions (possibly enabling them by default)1 0 -1
0
- OpenID enabling patch for OpenSSL and PHP 5
1 0 -1
0
- Add array_replace[_recursive] functions (patch is already
available)1 0 -1
0
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
1 0 -1
+1
And 0 for the rest of them.
Since my vote counts for shyte, I'll humbly offer brief remarks instead.
Ilia Alshanetsky queried:
- Remove safe_mode, register_globals and magic_quotes
1 0 -1
Major BC break in a minor version? Ouch. This should wait I think.
- Introduce mysqlind library into core and use it as a
backend for PDO and mysqli extensions (possibly enabling them
by default)1 0 -1
The mysqlind driver is currently alpha. Wherever it goes it should be marked
EXPERIMENTAL and off by default Frankly, I'm wondering (out loud) if PEAR
wouldn't be a better place for it until PHP6?
Best Regards
Mike Robinson
- Backport the namespaces patch for PHP 6
1 0 -1
+1
- Symlink the intl extension from PECL, but leave it disabled by
default as is the case with all extensions dependent on external libs1 0 -1
0
- Apply the Late Static Binding Patch
1 0 -1
+1
- Implement David's Circular Garbage collection patch
1 0 -1
+1
- Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)1 0 -1
+1
- Remove safe_mode, register_globals and magic_quotes
1 0 -1
-1 (Some php.net webs still use register_globals AND magic_quotes, I
don't think we can expect people to upgrade their scripts when not
even we have done so)
- Introduce mysqlind library into core and use it as a backend for
PDO and mysqli extensions (possibly enabling them by default)1 0 -1
+1
- OpenID enabling patch for OpenSSL and PHP 5
1 0 -1
+1
- Add array_replace[_recursive] functions (patch is already available)
1 0 -1
0
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
1 0 -1
+1
- Merge the zend_arg_info const'ify patch
1 0 -1
+1
- Merge the GCC 4 -fvisibility patch
1 0 -1
0
- Switch for disabling/enabling materialized cursors in mysqli
1 0 -1
+1 (wasn't this voted, and agreed, for for 5.2?)
- Link phar extension from PECL into core (possibly enabling it by
default)1 0 -1
0
- Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
1 0 -1
+1
- Introduce new php.ini files parser/scanner + CGI/FastCGI?
"htaccess" style ini file support1 0 -1
+1
- Merge __callStatic patch from PHP 6
1 0 -1
0
- Introduce concept of "strict classes" that do not permit dynamic
property creation1 0 -1
+1
-Hannes
- Backport the namespaces patch for PHP 6
-1
- Symlink the intl extension from PECL, but leave it disabled by default as
is the case with all extensions dependent on external libs
1
- Apply the Late Static Binding Patch
1
- Implement David's Circular Garbage collection patch
1
- Implement Sqlite3 support via the ext/sqlite extension (patch is already
available)
0
- Remove safe_mode, register_globals and magic_quotes
-1
- Introduce mysqlind library into core and use it as a backend for PDO and
mysqli extensions (possibly enabling them by default)
Only 1 if it's optional, -1 otherwise
- OpenID enabling patch for OpenSSL and PHP 5
1
- Add array_replace[_recursive] functions (patch is already available)
0
- Split off deprecation from
E_STRICT
intoE_DEPRECATED
1
- Merge the zend_arg_info const'ify patch
0
- Merge the GCC 4 -fvisibility patch
0
- Switch for disabling/enabling materialized cursors in mysqli
0
- Link phar extension from PECL into core (possibly enabling it by default)
0 for adding it to core, -1 to enable it by default
- Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
0
- Introduce new php.ini files parser/scanner + CGI/FastCGI? "htaccess" style
ini file support
0
- Merge __callStatic patch from PHP 6
1
- Introduce concept of "strict classes" that do not permit dynamic property
creation
1
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org