Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » PHP 5.3 Suggested Feature List »

PHP 5.3 Suggested Feature List

php.internals

Ilia A.

18 years ago
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 ---------------------------- 1) Backport the namespaces patch for PHP 6 1 0 -1 2) 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 3) Apply the Late Static Binding Patch 1 0 -1 4) Implement David's Circular Garbage collection patch 1 0 -1 5) Implement Sqlite3 support via the ext/sqlite extension (patch is already available) 1 0 -1 6) Remove safe_mode, register_globals and magic_quotes 1 0 -1 7) Introduce mysqlind library into core and use it as a backend for PDO and mysqli extensions (possibly enabling them by default) 1 0 -1 8) OpenID enabling patch for OpenSSL and PHP 5 1 0 -1 9) Add array_replace[_recursive] functions (patch is already available) 1 0 -1 10) Split off deprecation from E_STRICT into E_DEPRECATED 1 0 -1 11) Merge the zend_arg_info const'ify patch 1 0 -1 12) Merge the GCC 4 -fvisibility patch 1 0 -1 13) Switch for disabling/enabling materialized cursors in mysqli 1 0 -1 14) Link phar extension from PECL into core (possibly enabling it by default) 1 0 -1 15) Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch 1 0 -1 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? "htaccess" style ini file support 1 0 -1 17) Merge __callStatic patch from PHP 6 1 0 -1 18) Introduce concept of "strict classes" that do not permit dynamic property creation 1 0 -1 Ilia Alshanetsky

Larry Garfield

18 years ago
On Sunday 09 September 2007, 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.
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 > ---------------------------- > > 1) Backport the namespaces patch for PHP 6
1
> 2) 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.
> 3) Apply the Late Static Binding Patch
-1, unless we can guarantee no BC breakage with 5.2.
> 4) Implement David's Circular Garbage collection patch
I am not qualified to offer an intelligent opinion.
> 5) Implement Sqlite3 support via the ext/sqlite extension (patch is > already available)
1
> 6) 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.
> 7) 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.
> 8) OpenID enabling patch for OpenSSL and PHP 5
I have no opinion.
> 9) Add array_replace[_recursive] functions (patch is already available) > > 1 0 -1 > > 10) Split off deprecation from E_STRICT into E_DEPRECATED
1
> 11) Merge the zend_arg_info const'ify patch
I have no opinion.
> 12) Merge the GCC 4 -fvisibility patch
I am not qualified to offer an intelligent opinion.
> 13) Switch for disabling/enabling materialized cursors in mysqli
I have no opinion.
> 14) Link phar extension from PECL into core (possibly enabling it by > default)
I have no opinion.
> 15) Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
I am not qualified to offer an intelligent opinion.
> 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? > "htaccess" style ini file support
I have no opinion.
> 17) Merge __callStatic patch from PHP 6
1
> 18) 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

Greg Beaver

18 years ago
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 > ---------------------------- > > 1) Backport the namespaces patch for PHP 6
+1
> 2) Symlink the intl extension from PECL, but leave it disabled by > default as is the case with all extensions dependent on external libs
0
> 3) Apply the Late Static Binding Patch
+1
> 4) Implement David's Circular Garbage collection patch
0
> 5) Implement Sqlite3 support via the ext/sqlite extension (patch is > already available)
+1
> 6) Remove safe_mode, register_globals and magic_quotes
0
> 7) Introduce mysqlind library into core and use it as a backend for PDO > and mysqli extensions (possibly enabling them by default)
+2
> 8) OpenID enabling patch for OpenSSL and PHP 5
+1
> 9) Add array_replace[_recursive] functions (patch is already available)
+0
> 10) Split off deprecation from E_STRICT into E_DEPRECATED
+100000
> 11) Merge the zend_arg_info const'ify patch
0
> 12) Merge the GCC 4 -fvisibility patch
0
> 13) Switch for disabling/enabling materialized cursors in mysqli
0
> 14) 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).
> 15) Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
0
> 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? "htaccess" > style ini file support
+1
> 17) Merge __callStatic patch from PHP 6
+1
> 18) Introduce concept of "strict classes" that do not permit dynamic > property creation
-1 Thanks, Greg

Pierre Joye

18 years ago
On 9/9/07, Ilia Alshanetsky <ilia@prohost.org> 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 > ---------------------------- > > 1) Backport the namespaces patch for PHP 6 > > 1 0 -1
1
> 2) 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
Too early, we don't even have a release now. If it is stable by the end of the year (before RC1), then +1.
> 3) Apply the Late Static Binding Patch > > 1 0 -1
1
> 4) Implement David's Circular Garbage collection patch > > 1 0 -1
0
> 5) Implement Sqlite3 support via the ext/sqlite extension (patch is > already available) > > 1 0 -1
+1
> 6) Remove safe_mode, register_globals and magic_quotes > > 1 0 -1 > > 7) 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.
> 8) OpenID enabling patch for OpenSSL and PHP 5 > > 1 0 -1
+1 (there is nothing to vote on btw...)
> 9) Add array_replace[_recursive] functions (patch is already available) > > 1 0 -1
+1
> 10) Split off deprecation from E_STRICT into E_DEPRECATED > > 1 0 -1
+1
> 11) Merge the zend_arg_info const'ify patch > > 1 0 -1
+1
> 12) Merge the GCC 4 -fvisibility patch > > 1 0 -1
0
> 13) Switch for disabling/enabling materialized cursors in mysqli > > 1 0 -1
0
> 14) Link phar extension from PECL into core (possibly enabling it by > default) > > 1 0 -1
-1
> 15) Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch > > 1 0 -1
1
> 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? > "htaccess" style ini file support > > 1 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.
> 17) Merge __callStatic patch from PHP 6 > > 1 0 -1
1
> 18) Introduce concept of "strict classes" that do not permit dynamic > property creation > > 1 0 -1
1 --Pierre

David Coallier

18 years ago
On 9/9/07, Ilia Alshanetsky <ilia@prohost.org> 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 > ---------------------------- > > 1) Backport the namespaces patch for PHP 6 > > 1 0 -1
1
> > 2) 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
0
> > 3) Apply the Late Static Binding Patch > > 1 0 -1
1
> > 4) 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.
> > 5) Implement Sqlite3 support via the ext/sqlite extension (patch is > already available) > > 1 0 -1 >
1
> 6) 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.
> > 7) 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
> > 8) OpenID enabling patch for OpenSSL and PHP 5 > > 1 0 -1 >
1
> 9) Add array_replace[_recursive] functions (patch is already available) > > 1 0 -1 >
1
> 10) Split off deprecation from E_STRICT into E_DEPRECATED > > 1 0 -1 >
1 YES!
> 11) Merge the zend_arg_info const'ify patch > > 1 0 -1 >
1
> 12) Merge the GCC 4 -fvisibility patch > > 1 0 -1 >
0
> 13) Switch for disabling/enabling materialized cursors in mysqli > > 1 0 -1 >
1
> 14) Link phar extension from PECL into core (possibly enabling it by > default) > > 1 0 -1 >
1
> 15) Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch > > 1 0 -1 >
1
> 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? > "htaccess" style ini file support > > 1 0 -1 >
0
> 17) Merge __callStatic patch from PHP 6 > > 1 0 -1 >
1
> 18) Introduce concept of "strict classes" that do not permit dynamic > property creation > > 1 0 -1 >
1
> Ilia Alshanetsky > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
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

Lester Caine

18 years ago
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 > ---------------------------- > 6) Remove safe_mode, register_globals and magic_quotes
PHP6 ONLY Lets not have another round of broken systems when just upgrading a minor version.
> 7) 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

Nuno Lopes

18 years ago
> 1) Backport the namespaces patch for PHP 6
> 2) 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.
> 3) Apply the Late Static Binding Patch
+0
> 4) Implement David's Circular Garbage collection patch
+1
> 5) Implement Sqlite3 support via the ext/sqlite extension (patch is > already available)
+1
> 6) Remove safe_mode, register_globals and magic_quotes
-1
> 7) 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
> 8) OpenID enabling patch for OpenSSL and PHP 5
+1
> 9) Add array_replace[_recursive] functions (patch is already available)
+0
> 10) Split off deprecation from E_STRICT into E_DEPRECATED
+0
> 11) Merge the zend_arg_info const'ify patch
+1 (biased)
> 12) Merge the GCC 4 -fvisibility patch
+1 (biased)
> 13) Switch for disabling/enabling materialized cursors in mysqli
> 14) Link phar extension from PECL into core (possibly enabling it by default)
0, but not by default.
> 15) Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
+1 The patch is pretty simple. it just needs some typedefs to work on windows.
> 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? > "htaccess" style ini file support
+1, but with the option to disable it.
> 17) Merge __callStatic patch from PHP 6
> 18) Introduce concept of "strict classes" that do not permit dynamic > property creation
-0 Nuno

Antony Dovgal

18 years ago
On 09.09.2007 21:07, 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 > ---------------------------- > > 1) Backport the namespaces patch for PHP 6 > > 1 0 -1
I thought most of us agreed that 5.3 should be == (PHP6 - Unicode). 1
> 2) 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
Once it's ready for production - why not? 1
> 3) Apply the Late Static Binding Patch > > 1 0 -1
0
> 4) Implement David's Circular Garbage collection patch > > 1 0 -1
IIRC that's one of the reasons for 5.3 branch. 1
> 5) 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).
> 6) Remove safe_mode, register_globals and magic_quotes > > 1 0 -1
Let's leave this for HEAD. -1
> 7) 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".
> 8) OpenID enabling patch for OpenSSL and PHP 5 > > 1 0 -1
0
> 9) 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
> 10) Split off deprecation from E_STRICT into E_DEPRECATED > > 1 0 -1
-1 Didn't see any arguments for this.
> 11) Merge the zend_arg_info const'ify patch > > 1 0 -1
0
> 12) Merge the GCC 4 -fvisibility patch > > 1 0 -1
0
> 13) Switch for disabling/enabling materialized cursors in mysqli > > 1 0 -1
0
> 14) Link phar extension from PECL into core (possibly enabling it by > default) > > 1 0 -1
0 (-1 for enabling it by default).
> 15) 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.
> 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? > "htaccess" style ini file support > > 1 0 -1
0 AFAIK it's too early.
> 17) 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)?
> 18) Introduce concept of "strict classes" that do not permit dynamic > property creation > > 1 0 -1
0
-- Wbr, Antony Dovgal

David Coallier

18 years ago
On 9/9/07, Antony Dovgal <tony@daylessday.org> wrote:
> On 09.09.2007 21:07, 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 > > ---------------------------- > > > > 1) Backport the namespaces patch for PHP 6 > > > > 1 0 -1 > > I thought most of us agreed that 5.3 should be == (PHP6 - Unicode). > 1 > > > 2) 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 > > Once it's ready for production - why not? > 1 > > > 3) Apply the Late Static Binding Patch > > > > 1 0 -1 > > 0 > > > 4) Implement David's Circular Garbage collection patch > > > > 1 0 -1 > > IIRC that's one of the reasons for 5.3 branch. > 1 > > > 5) 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). > > > 6) Remove safe_mode, register_globals and magic_quotes > > > > 1 0 -1 > > Let's leave this for HEAD. > -1 > > > 7) 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". > > > 8) OpenID enabling patch for OpenSSL and PHP 5 > > > > 1 0 -1 > > 0 > > > 9) 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 > > > 10) Split off deprecation from E_STRICT into E_DEPRECATED > > > > 1 0 -1 > > -1 > Didn't see any arguments for this.
http://marc.info/?l=php-dev&m=116163053224532&w=2
> > > 11) Merge the zend_arg_info const'ify patch > > > > 1 0 -1 > > 0 > > > 12) Merge the GCC 4 -fvisibility patch > > > > 1 0 -1 > > 0 > > > 13) Switch for disabling/enabling materialized cursors in mysqli > > > > 1 0 -1 > > 0 > > > 14) Link phar extension from PECL into core (possibly enabling it by > > default) > > > > 1 0 -1 > > 0 (-1 for enabling it by default). > > > 15) 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. > > > 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? > > "htaccess" style ini file support > > > > 1 0 -1 > > 0 > AFAIK it's too early. > > > 17) 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
> > 18) Introduce concept of "strict classes" that do not permit dynamic > > property creation > > > > 1 0 -1 > > 0 > > -- > Wbr, > Antony Dovgal > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18

Brian Moon

18 years ago
All none listed are zero for me.
> 1) Backport the namespaces patch for PHP 6
1
> 6) Remove safe_mode, register_globals and magic_quotes
-1
> 7) Introduce mysqlind library into core and use it as a backend for PDO > and mysqli extensions (possibly enabling them by default)
1
> 8) OpenID enabling patch for OpenSSL and PHP 5
1
> 9) Add array_replace[_recursive] functions (patch is already available)
1
> 10) Split off deprecation from E_STRICT into E_DEPRECATED
1
> 16) 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 =)

Stanislav Malyshev

18 years ago
> 1) Backport the namespaces patch for PHP 6
1 as soon as we have it stabilized.
> 2) Symlink the intl extension from PECL, but leave it disabled by > default as is the case with all extensions dependent on external libs
1
> 3) Apply the Late Static Binding Patch
1
> 4) Implement David's Circular Garbage collection patch
Only if no significant performance degradation or one could turn it on/off at will.
> 5) Implement Sqlite3 support via the ext/sqlite extension (patch is > already available)
1
> 6) 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 ;)
> 7) 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.
> 8) OpenID enabling patch for OpenSSL and PHP 5
1
> 9) Add array_replace[_recursive] functions (patch is already available)
0
> 10) Split off deprecation from E_STRICT into E_DEPRECATED
0. Why do we *need* it again?
> 11) Merge the zend_arg_info const'ify patch
1
> 12) Merge the GCC 4 -fvisibility patch
1
> 13) Switch for disabling/enabling materialized cursors in mysqli
0
> 14) Link phar extension from PECL into core (possibly enabling it by > default)
-1, we discussed why :) 0 if not enabled by default.
> 15) Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
1
> 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? "htaccess" > style ini file support
0. 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.
> 17) Merge __callStatic patch from PHP 6
1 with all other __static too.
> 18) 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

Lukas Kahwe Smith

18 years ago
Stanislav Malyshev wrote:
>> 10) Split off deprecation from E_STRICT into E_DEPRECATED > > 0. 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

Stanislav Malyshev

18 years ago
> 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.
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

Keryx Web

18 years ago
Lukas Kahwe Smith skrev:
> Stanislav Malyshev wrote: > >>> 10) Split off deprecation from E_STRICT into E_DEPRECATED >> >> 0. 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 ignoring E_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

LAUPRETRE François (P)

18 years ago
> From: Stanislav Malyshev [mailto:stas@zend.com] > > > 14) Link phar extension from PECL into core (possibly enabling it by > > default) > > -1, we discussed why :) 0 if not enabled by default.
Yes, it was discussed, and I thought it was clear for everybody that phar had to remain in pecl and was not mature enough for core. Once again, as we don't have any formal RFC/decision process, people whose proposal was clearly rejected/delayed can still have it approved: they just have to wait a little and, then, hide it in the middle of a bunch of more important votes. Once your software is in the core, it is easy: if somebody wants to remove it, you invoke BC breaks ! That's exactly what is done here. As most people forgot the discussion about PHAR vs PHK, it is proposed again, but today it is hidden into a lot of more problematic decisions, like register_globals and safe_mode, which will generate a lot of buzz and help keep it hidden. I proposed several times to implement a more formal RFC process for PHP but didn't get much success. As the Zend Framework has implemented such a tool, what would you think of a similar site for the PHP core ? Francois

Marcus Börger

18 years ago
Hello LAUPRETRE, to cut this short. Noone tried to overrule anyone and noone tried to outsmart or trick in any sense either. In the past we decided on the following. First it is to early to ring in Phar for a variety of reasons. As development went on it was more than appropriate for the RM to ask whether this might have related in a change of opinions. And btw, basically you are doing the same thing here, by mentioning PHK again and again you do not get any benefit either :-) Instead you need to put PHK into PECL and follow all rules before being able to oppose Phar with PHK. marcus Wednesday, September 12, 2007, 2:07:28 PM, you wrote:
>> From: Stanislav Malyshev [mailto:stas@zend.com] >> >> > 14) Link phar extension from PECL into core (possibly enabling it by >> > default) >> >> -1, we discussed why :) 0 if not enabled by default.
> Yes, it was discussed, and I thought it was clear for everybody that phar had to remain > in pecl and was not mature enough for core.
> Once again, as we don't have any formal RFC/decision process, people whose proposal was > clearly rejected/delayed can still have it approved: they just have to wait a little > and, then, hide it in the middle of a bunch of more important votes. Once your software > is in the core, it is easy: if somebody wants to remove it, you invoke BC breaks !
> That's exactly what is done here. As most people forgot the discussion about PHAR vs > PHK, it is proposed again, but today it is hidden into a lot of more problematic > decisions, like register_globals and safe_mode, which will generate a lot of buzz and > help keep it hidden.
> I proposed several times to implement a more formal RFC process for PHP but didn't get > much success. As the Zend Framework has implemented such a tool, what would you think > of a similar site for the PHP core ?
> Francois
Best regards, Marcus

Johannes Schlueter

18 years ago
Hi Ilia, On Sunday 09 September 2007 07:07:37 pm Ilia Alshanetsky wrote:
> List of Feature Ideas > ---------------------------- > > 1) Backport the namespaces patch for PHP 6 > > 1 0 -1
+1
> 2) 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
From what I read that extension offers interesting stuff. +1
> 3) Apply the Late Static Binding Patch > > 1 0 -1
0
> 4) 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
> 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
> 6) Remove safe_mode, register_globals and magic_quotes > > 1 0 -1
-1
> 7) 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
> 8) OpenID enabling patch for OpenSSL and PHP 5 > > 1 0 -1
+1
> 9) 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
> 10) Split off deprecation from E_STRICT into E_DEPRECATED > > 1 0 -1
0
> 11) Merge the zend_arg_info const'ify patch > > 1 0 -1
+1
> 12) Merge the GCC 4 -fvisibility patch > > 1 0 -1
0
> 13) Switch for disabling/enabling materialized cursors in mysqli > > 1 0 -1
0
> 14) Link phar extension from PECL into core (possibly enabling it by > default) > > 1 0 -1
+1
> 15) Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch > > 1 0 -1
+1
> 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? > "htaccess" style ini file support > > 1 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
> 17) Merge __callStatic patch from PHP 6 > > 1 0 -1
+1
> 18) Introduce concept of "strict classes" that do not permit dynamic > property creation > > 1 0 -1
0 johannes
-- Johannes Schlüter http://schlueters.de

Scott MacVicar

18 years ago
On 9 Sep 2007, at 13:07, 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 > ---------------------------- > > 1) Backport the namespaces patch for PHP 6 > > 1 0 -1
+1
> > 2) 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
+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.
> > 3) Apply the Late Static Binding Patch > > 1 0 -1
+1
> > 4) 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.
> > 5) 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.
> 6) 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.
> > 7) 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
> > 8) OpenID enabling patch for OpenSSL and PHP 5 > > 1 0 -1 >
0
> 9) Add array_replace[_recursive] functions (patch is already > available) > > 1 0 -1 >
0
> 10) Split off deprecation from E_STRICT into E_DEPRECATED > > 1 0 -1 >
+1
> 11) Merge the zend_arg_info const'ify patch > > 1 0 -1 >
+1
> 12) Merge the GCC 4 -fvisibility patch > > 1 0 -1 >
0
> 13) Switch for disabling/enabling materialized cursors in mysqli > > 1 0 -1 >
0
> 14) Link phar extension from PECL into core (possibly enabling it > by default) > > 1 0 -1 >
-1
> 15) Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch > > 1 0 -1 >
+1
> 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? > "htaccess" style ini file support > > 1 0 -1 >
+1
> 17) Merge __callStatic patch from PHP 6 > > 1 0 -1 >
+1
> 18) Introduce concept of "strict classes" that do not permit > dynamic property creation > > 1 0 -1 >
+1 Scott

Lester Caine

18 years ago
Scott MacVicar wrote:
>> 6) 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

Larry Garfield

18 years ago
On Monday 10 September 2007, Lester Caine wrote:
> Scott MacVicar wrote: > >> 6) 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

Pierre Joye

18 years ago
On 9/10/07, Larry Garfield <larry@garfieldtech.com> wrote:
> On Monday 10 September 2007, Lester Caine wrote: > > Scott MacVicar wrote: > > >> 6) 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

Al Baker

18 years ago
Comments inline On Sun, 2007-09-09 at 13:07 -0400, 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 > ---------------------------- > > 1) Backport the namespaces patch for PHP 6 > > 1 0 -1
1
> > 2) 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 >
0
> 3) Apply the Late Static Binding Patch > > 1 0 -1 >
0
> 4) Implement David's Circular Garbage collection patch > > 1 0 -1 >
1
> 5) 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
> 6) Remove safe_mode, register_globals and magic_quotes > > 1 0 -1 >
0
> 7) 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
> > 8) OpenID enabling patch for OpenSSL and PHP 5 > > 1 0 -1 >
1
> 9) Add array_replace[_recursive] functions (patch is already available) > > 1 0 -1 >
0
> 10) Split off deprecation from E_STRICT into E_DEPRECATED > > 1 0 -1 >
1
> 11) Merge the zend_arg_info const'ify patch > > 1 0 -1 >
0
> 12) Merge the GCC 4 -fvisibility patch > > 1 0 -1 >
0
> 13) Switch for disabling/enabling materialized cursors in mysqli > > 1 0 -1 >
0
> 14) Link phar extension from PECL into core (possibly enabling it by > default) > > 1 0 -1 >
1
> 15) Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch > > 1 0 -1 >
1
> 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? > "htaccess" style ini file support > > 1 0 -1 >
1
> 17) Merge __callStatic patch from PHP 6 > > 1 0 -1 >
0
> 18) Introduce concept of "strict classes" that do not permit dynamic > property creation > > 1 0 -1 >
1, if you can disable it to have dynamic property creation (a great feature of PHP in my opinion)

Emil Ivanov

18 years ago
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 > ---------------------------- > > 1) Backport the namespaces patch for PHP 6 > > 1 0 -1 >
+1
> 2) 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
0
> > 3) Apply the Late Static Binding Patch > > 1 0 -1
+1
> > 4) Implement David's Circular Garbage collection patch > > 1 0 -1
0
> > 5) Implement Sqlite3 support via the ext/sqlite extension (patch is > already available) > > 1 0 -1
+1
> > 6) Remove safe_mode, register_globals and magic_quotes > > 1 0 -1
-2
> > 7) 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
> > 8) OpenID enabling patch for OpenSSL and PHP 5 > > 1 0 -1
0
> > 9) Add array_replace[_recursive] functions (patch is already available) > > 1 0 -1
+1
> > 10) Split off deprecation from E_STRICT into E_DEPRECATED > > 1 0 -1
+1
> > 11) Merge the zend_arg_info const'ify patch > > 1 0 -1
0
> > 12) Merge the GCC 4 -fvisibility patch > > 1 0 -1
0
> > 13) Switch for disabling/enabling materialized cursors in mysqli > > 1 0 -1
+1
> > 14) Link phar extension from PECL into core (possibly enabling it by > default) > > 1 0 -1
+1 (Depends how it will cope with namespaces?)
> > 15) Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch > > 1 0 -1
0
> > 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? "htaccess" > style ini file support > > 1 0 -1
0
> > 17) Merge __callStatic patch from PHP 6 > > 1 0 -1
+1
> > 18) Introduce concept of "strict classes" that do not permit dynamic > property creation > > 1 0 -1
0 Regards, Emil Ivanov

Greg Beaver

18 years ago
emo wrote:
>> 14) 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

Emil Ivanov

18 years ago
My bad, please ignore the comment. Thanks Greg. Regards, Emil Ivanov Gregory Beaver wrote:

Rob Richards

18 years ago
> 1) Backport the namespaces patch for PHP 6
0
> 2) Symlink the intl extension from PECL, but leave it disabled by > default as is the case with all extensions dependent on external libs
1
> 3) Apply the Late Static Binding Patch
1
> 4) Implement David's Circular Garbage collection patch
0
> 5) Implement Sqlite3 support via the ext/sqlite extension (patch is > already available)
0
> 6) Remove safe_mode, register_globals and magic_quotes
0
> 7) 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)
> > 8) 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.
> 9) Add array_replace[_recursive] functions (patch is already available)
0
> 10) Split off deprecation from E_STRICT into E_DEPRECATED
0
> > 11) Merge the zend_arg_info const'ify patch
1
> 12) Merge the GCC 4 -fvisibility patch
1
> 13) Switch for disabling/enabling materialized cursors in mysqli
1
> > 14) Link phar extension from PECL into core (possibly enabling it by > default)
0
> 15) Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
1
> 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? > "htaccess" style ini file support
0
> 17) Merge __callStatic patch from PHP 6
0
> 18) Introduce concept of "strict classes" that do not permit dynamic > property creation
0 Rob

Pierre Joye

18 years ago
Hi Rob, On 9/10/07, Rob Richards <rrichards@ctindustries.net> wrote:
> > 8) 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

Lukas Kahwe Smith

18 years ago
Ilia Alshanetsky wrote:
> 1) Backport the namespaces patch for PHP 6
+1
> 3) Apply the Late Static Binding Patch
+1
> 5) Implement Sqlite3 support via the ext/sqlite extension (patch is > already available)
+1
> 6) Remove safe_mode, register_globals and magic_quotes
-1
> 7) 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)
> 8) OpenID enabling patch for OpenSSL and PHP 5
+1
> 9) 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)
> 10) Split off deprecation from E_STRICT into E_DEPRECATED
+1
> 14) Link phar extension from PECL into core (possibly enabling it by > default)
+1
> 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? "htaccess" > style ini file support
+1
> 18) 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

SoftVirus

18 years ago
> 1) Backport the namespaces patch for PHP 6
1
> 2) Symlink the intl extension from PECL, but leave it disabled by
default as is the case with all extensions dependent on external libs 0
> 3) Apply the Late Static Binding Patch
1
> 4) Implement David's Circular Garbage collection patch
0
> 5) Implement Sqlite3 support via the ext/sqlite extension (patch is
already available) 0
> 6) Remove safe_mode, register_globals and magic_quotes
1 ( as long we allow old codes to functions )
> 7) Introduce mysqlind library into core and use it as a backend for
PDO and mysqli extensions (possibly enabling them by default) 0
> 8) OpenID enabling patch for OpenSSL and PHP 5
0
> 9) Add array_replace[_recursive] functions (patch is already available)
1
> 10) Split off deprecation from E_STRICT into E_DEPRECATED
1
> 11) Merge the zend_arg_info const'ify patch
0
> 12) Merge the GCC 4 -fvisibility patch
0
> 13) Switch for disabling/enabling materialized cursors in mysqli
0
> 14) Link phar extension from PECL into core (possibly enabling it by
default) 0
> 15) Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
0
> 16) Introduce new php.ini files parser/scanner + CGI/FastCGI?
"htaccess" style ini file support 0
> 17) Merge __callStatic patch from PHP 6
1
> 18) Introduce concept of "strict classes" that do not permit dynamic
property creation 0

Marcus Börger

18 years ago
Hello Ilia, Sunday, September 9, 2007, 7:07:37 PM, you wrote:
> 1) Backport the namespaces patch for PHP 6
+1
> 2) Symlink the intl extension from PECL, but leave it disabled by
+1
> 3) Apply the Late Static Binding Patch
+1
> 4) Implement David's Circular Garbage collection patch
+1
> 5) Implement Sqlite3 support via the ext/sqlite extension (patch is > already available)
+1
> 6) Remove safe_mode, register_globals and magic_quotes
remove register_globals only, rest for 6.*
> 7) Introduce mysqlind library into core and use it as a backend for > PDO and mysqli extensions (possibly enabling them by default)
+1
> 8) OpenID enabling patch for OpenSSL and PHP 5
+1
> 9) Add array_replace[_recursive] functions (patch is already available)
+1
> 10) Split off deprecation from E_STRICT into E_DEPRECATED
+1
> 11) Merge the zend_arg_info const'ify patch
+1 (even though it is me who has to do it i guess :-)
> 12) Merge the GCC 4 -fvisibility patch
0
> 13) Switch for disabling/enabling materialized cursors in mysqli
0
> 14) Link phar extension from PECL into core (possibly enabling it by > default)
+1
> 15) Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
+1
> 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? > "htaccess" style ini file support
+1
> 17) Merge __callStatic patch from PHP 6
+1
> 18) Introduce concept of "strict classes" that do not permit dynamic > property creation
0, we could eventually do this via an interface Best regards, Marcus

Marcus Börger

18 years ago
Hello Ilia, Monday, September 10, 2007, 3:08:57 PM, you wrote:
> Hello Ilia,
> Sunday, September 9, 2007, 7:07:37 PM, you wrote:
>> 6) 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

Stephan Schmidt

18 years ago
Hi, Ilia Alshanetsky wrote:
> List of Feature Ideas > ---------------------------- > > 1) Backport the namespaces patch for PHP 6
+1
> 2) Symlink the intl extension from PECL, but leave it disabled by > default as is the case with all extensions dependent on external libs
0
> 3) Apply the Late Static Binding Patch
+1
> 4) Implement David's Circular Garbage collection patch
-1
> 5) Implement Sqlite3 support via the ext/sqlite extension (patch is > already available)
0
> 6) Remove safe_mode, register_globals and magic_quotes
+1
> 7) Introduce mysqlind library into core and use it as a backend for PDO > and mysqli extensions (possibly enabling them by default)
0
> 8) OpenID enabling patch for OpenSSL and PHP 5
0
> 9) Add array_replace[_recursive] functions (patch is already available)
+1
> 10) Split off deprecation from E_STRICT into E_DEPRECATED
+1
> 11) Merge the zend_arg_info const'ify patch
0
> 12) Merge the GCC 4 -fvisibility patch
0
> 13) Switch for disabling/enabling materialized cursors in mysqli
0
> 14) Link phar extension from PECL into core (possibly enabling it by > default)
+1
> 15) Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
0
> 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? "htaccess" > style ini file support
0
> 17) Merge __callStatic patch from PHP 6
+1
> 18) Introduce concept of "strict classes" that do not permit dynamic > property creation
+1 Best regards, Stephan

Andi Gutmans

18 years ago
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 List > > > List of Feature Ideas > ---------------------------- > > 1) Backport the namespaces patch for PHP 6 > > 1 0 -1
+1 (pending it's stable and complete).
> 2) 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
+1
> 3) 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).
> 4) Implement David's Circular Garbage collection patch > > 1 0 -1
+1 (depending on tests, perf and maturity we can decide on optional/experimental/etc...)
> 5) Implement Sqlite3 support via the ext/sqlite extension (patch is > already available) > > 1 0 -1
0
> 6) Remove safe_mode, register_globals and magic_quotes > > 1 0 -1
-1
> 7) 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
> 8) OpenID enabling patch for OpenSSL and PHP 5 > > 1 0 -1
+1
> 9) Add array_replace[_recursive] functions (patch is already
available)
> > 1 0 -1
+1
> 10) Split off deprecation from E_STRICT into E_DEPRECATED > > 1 0 -1
+1
> 11) Merge the zend_arg_info const'ify patch > > 1 0 -1
0
> 12) Merge the GCC 4 -fvisibility patch > > 1 0 -1
0
> 13) Switch for disabling/enabling materialized cursors in mysqli > > 1 0 -1
0
> 14) 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))
> 15) Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch > > 1 0 -1
+1
> 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? > "htaccess" style ini file support > > 1 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).
> 17) Merge __callStatic patch from PHP 6 > > 1 0 -1
+1
> 18) Introduce concept of "strict classes" that do not permit dynamic > property creation > > 1 0 -1
-1

Pierre Joye

18 years ago
On 9/10/07, Andi Gutmans <andi@zend.com> wrote:
> 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 List > > > > > > List of Feature Ideas > > ---------------------------- > > > > 1) Backport the namespaces patch for PHP 6 > > > > 1 0 -1 > > +1 (pending it's stable and complete). > > > > 2) 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 > > +1 > > > > 3) 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). > > > 4) Implement David's Circular Garbage collection patch > > > > 1 0 -1 > > +1 (depending on tests, perf and maturity we can decide on > optional/experimental/etc...) > > > 5) Implement Sqlite3 support via the ext/sqlite extension (patch is > > already available) > > > > 1 0 -1 > > 0 > > > 6) Remove safe_mode, register_globals and magic_quotes > > > > 1 0 -1 > > -1 > > > 7) 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 > > > 8) OpenID enabling patch for OpenSSL and PHP 5 > > > > 1 0 -1 > > +1 > > > > 9) Add array_replace[_recursive] functions (patch is already > available) > > > > 1 0 -1 > > > +1 > > > > 10) Split off deprecation from E_STRICT into E_DEPRECATED > > > > 1 0 -1 > > +1 > > > 11) Merge the zend_arg_info const'ify patch > > > > 1 0 -1 > > 0 > > > 12) Merge the GCC 4 -fvisibility patch > > > > 1 0 -1 > > 0 > > > 13) Switch for disabling/enabling materialized cursors in mysqli > > > > 1 0 -1 > > 0 > > > 14) 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)) > > > 15) Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch > > > > 1 0 -1 > > +1 > > > 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? > > "htaccess" style ini file support > > > > 1 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

Andi Gutmans

18 years ago
> -----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 List > > 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).
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

Jani Taskinen

18 years ago
On Mon, 2007-09-10 at 22:56 +0200, Pierre wrote:
> On 9/10/07, Andi Gutmans <andi@zend.com> wrote: > > > 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? > > > "htaccess" style ini file support > > > > > > 1 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/

Pierre Joye

18 years ago
On 9/11/07, Jani Taskinen <jani.taskinen@sci.fi> wrote:
> On Mon, 2007-09-10 at 22:56 +0200, Pierre wrote: > > On 9/10/07, Andi Gutmans <andi@zend.com> wrote: > > > > 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? > > > > "htaccess" style ini file support > > > > > > > > 1 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

Greg Beaver

18 years ago
Andi Gutmans wrote:
>> 14) 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 Gutmans

18 years ago
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 List > > Andi Gutmans wrote: > >> 14) Link phar extension from PECL into core (possibly enabling it
by

David Coallier

18 years ago
On 9/10/07, Andi Gutmans <andi@zend.com> wrote:
> 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 List > > > > Andi Gutmans wrote: > > >> 14) 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
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

Andi Gutmans

18 years ago
> -----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 List > > Andi, 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

Greg Beaver

18 years ago
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 List >> >> Andi, 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

Andi Gutmans

18 years ago
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

Marcus Börger

18 years ago
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 List >> >> >> >> Andi, 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

Dmitry Stogov

18 years ago
Hi, I've attached my PHAR variation that was made some time ago just to prove the concept. It uses standard TAR format and doesn't use any external libraries. In case if you call "php test.tar.gz", PHP (with this extension) will execute file main.php from the archive. I cannot remember wich version of PHAR I used in benchmarks, but TAR was faster. Thanks. Dmitry.

Dale Walsj

18 years ago
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 11, 2007, at 05:42:50, Marcus Boerger 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?
> > marcus
- -- Dale -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFG5oxg0hzWbkf0eKgRAq03AKDOy7h6XGSg9nZ4C5ZdCCkmu+0dyACdH8VB 4aUIE+OBi0ArJG5W+mYxf2U= =tWzE -----END PGP SIGNATURE-----

Jani Taskinen

18 years ago
On Mon, 2007-09-10 at 13:47 -0700, Andi Gutmans wrote:
>> 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? > > "htaccess" style ini file support > > > > 1 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/

Cristian Rodriguez

18 years ago
On 9/9/07, Ilia Alshanetsky <ilia@prohost.org> wrote:
> 12) 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.
-- http://www.kissofjudas.net/

Stanislav Malyshev

18 years ago
> 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

Nuno Lopes

18 years ago
>> 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

Andrei Zmievski

18 years ago
Ilia Alshanetsky wrote:
> List of Feature Ideas > ---------------------------- > > 1) Backport the namespaces patch for PHP 6
-1
> 2) Symlink the intl extension from PECL, but leave it disabled by > default as is the case with all extensions dependent on external libs
1
> 3) Apply the Late Static Binding Patch > > 1 0 -1
1
> 4) Implement David's Circular Garbage collection patch
-1
> 5) Implement Sqlite3 support via the ext/sqlite extension (patch is > already available)
1
> 6) Remove safe_mode, register_globals and magic_quotes
-1
> 7) Introduce mysqlind library into core and use it as a backend for PDO > and mysqli extensions (possibly enabling them by default)
0
> 8) OpenID enabling patch for OpenSSL and PHP 5
1
> 9) Add array_replace[_recursive] functions (patch is already available)
1
> 10) Split off deprecation from E_STRICT into E_DEPRECATED
1
> 11) Merge the zend_arg_info const'ify patch
1
> 12) Merge the GCC 4 -fvisibility patch
1
> 13) Switch for disabling/enabling materialized cursors in mysqli
0
> 14) Link phar extension from PECL into core (possibly enabling it by > default)
1
> 15) Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
1
> 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? "htaccess" > style ini file support
0
> 17) Merge __callStatic patch from PHP 6
0
> 18) 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

Sebastian Bergmann

18 years ago
Ilia Alshanetsky wrote:
> 1) Backport the namespaces patch for PHP 6
0
> 2) Symlink the intl extension from PECL, but leave it disabled by > default as is the case with all extensions dependent on external libs
0
> 3) Apply the Late Static Binding Patch
1
> 4) Implement David's Circular Garbage collection patch
1
> 5) Implement Sqlite3 support via the ext/sqlite extension (patch is > already available)
0
> 6) Remove safe_mode, register_globals and magic_quotes
0
> 7) Introduce mysqlind library into core and use it as a backend for PDO > and mysqli extensions (possibly enabling them by default)
1
> 8) OpenID enabling patch for OpenSSL and PHP 5
1
> 9) Add array_replace[_recursive] functions (patch is already available)
1
> 10) Split off deprecation from E_STRICT into E_DEPRECATED
1
> 11) Merge the zend_arg_info const'ify patch
1
> 12) Merge the GCC 4 -fvisibility patch
1
> 13) Switch for disabling/enabling materialized cursors in mysqli
0
> 14) Link phar extension from PECL into core (possibly enabling it by > default)
0
> 15) Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
0
> 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? "htaccess" > style ini file support
0
> 17) Merge __callStatic patch from PHP 6
1
> 18) 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

Dmitry Stogov

18 years ago
> 1) Backport the namespaces patch for PHP 6
+1
> 3) Apply the Late Static Binding Patch
+1
> 6) Remove safe_mode, register_globals and magic_quotes
-1
> 8) OpenID enabling patch for OpenSSL and PHP 5
+1 10) Split off deprecation from E_STRICT into E_DEPRECATED +1 11) Merge the zend_arg_info const'ify patch +1 14) Link phar extension from PECL into core (possibly enabling it by default) +1 BTW, I would prefer something more toolable (like TAR or ZIP)
> 15) Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
+1
> 17) Merge __callStatic patch from PHP 6
+1
> 18) Introduce concept of "strict classes" that do not permit dynamic > property creation
-1 Thanks. Dmitry.

Michael Wallner

18 years ago
Ilia Alshanetsky wrote:
> 1) Backport the namespaces patch for PHP 6
+1
> 2) 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)
> 3) Apply the Late Static Binding Patch
+1
> 4) Implement David's Circular Garbage collection patch
0 (is this really something for a minor version?)
> 5) Implement Sqlite3 support via the ext/sqlite extension (patch is > already available)
0
> 6) Remove safe_mode, register_globals and magic_quotes
-1 (never used any, but I'd say leave that items up for the next major)
> 7) 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)
> 8) OpenID enabling patch for OpenSSL and PHP 5
+1
> 9) Add array_replace[_recursive] functions (patch is already available)
0
> 10) Split off deprecation from E_STRICT into E_DEPRECATED
+1
> 11) Merge the zend_arg_info const'ify patch
+1
> 12) Merge the GCC 4 -fvisibility patch
-1 (eventually make it a configure option first? PHP is a API mess)
> 13) Switch for disabling/enabling materialized cursors in mysqli
0
> 14) Link phar extension from PECL into core (possibly enabling it by > default)
+1
> 15) Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
+1
> 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? "htaccess" > style ini file support
+1
> 17) Merge __callStatic patch from PHP 6
+1
> 18) Introduce concept of "strict classes" that do not permit dynamic > property creation
+1 Regards,
-- Michael

Nuno Lopes

18 years ago
>> 12) 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

Philip Olson

18 years ago
> 1) Backport the namespaces patch for PHP 6
1
> 2) Symlink the intl extension from PECL, but leave it disabled by > default as is the case with all extensions dependent on external libs
1
> 3) Apply the Late Static Binding Patch
1
> 4) Implement David's Circular Garbage collection patch
0
> 5) Implement Sqlite3 support via the ext/sqlite extension (patch is > already available)
1
> 6) Remove safe_mode, register_globals and magic_quotes
-1, and only RG has had appropriate warning/info thus far.
> 7) Introduce mysqlind library into core and use it as a backend for > PDO and mysqli extensions (possibly enabling them by default)
1
> 8) OpenID enabling patch for OpenSSL and PHP 5
1
> 9) Add array_replace[_recursive] functions (patch is already > available)
1
> 10) Split off deprecation from E_STRICT into E_DEPRECATED
1
> 11) Merge the zend_arg_info const'ify patch
1
> 12) Merge the GCC 4 -fvisibility patch
1
> 13) Switch for disabling/enabling materialized cursors in mysqli
0
> 14) Link phar extension from PECL into core (possibly enabling it > by default)
0
> 15) Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
0
> 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? > "htaccess" style ini file support
1
> 17) Merge __callStatic patch from PHP 6
1
> 18) Introduce concept of "strict classes" that do not permit > dynamic property creation
-1 E_FATAL, +1 E_STRICT Regards, Philip

Steph

18 years ago
If it counts for anything, here's my vote on the bits I know/care about:
> 2) 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
> 3) Apply the Late Static Binding Patch
+1, I'll probably never use it but I can see where others might
> 5) Implement Sqlite3 support via the ext/sqlite extension (patch is > already available)
+1, assuming this won't kill sqlite2 support (where's the patch?)
> 6) 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
> 7) 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
> 8) OpenID enabling patch for OpenSSL and PHP 5
+1, is there even an argument against this?
> 10) Split off deprecation from E_STRICT into E_DEPRECATED
+1, about time!
> 14) Link phar extension from PECL into core (possibly enabling it by > default)
+1, I think this could help tremendously with application deployment
> 15) Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
+1, we all love Matt
> 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? "htaccess" > style ini file support
0 - very torn over this idea
> 17) Merge __callStatic patch from PHP 6
+1
> 18) Introduce concept of "strict classes" that do not permit dynamic > property creation
-1, this whole idea just sounds so weird for PHP. - Steph

Michael Wallner

18 years ago
Steph Fox wrote:
>> 18) 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

Steph

18 years ago
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 1 > > The 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

David Zülke

18 years ago
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 > ---------------------------- > > 1) Backport the namespaces patch for PHP 6 > > 1 0 -1
+1
> 2) 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
-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.
> 3) Apply the Late Static Binding Patch > > 1 0 -1
+1
> 4) Implement David's Circular Garbage collection patch > > 1 0 -1
-1 Is that really tested well enough already?
> 5) Implement Sqlite3 support via the ext/sqlite extension (patch is > already available) > > 1 0 -1
0
> 6) Remove safe_mode, register_globals and magic_quotes > > 1 0 -1
-1 Why break BC in a .x release?
> 7) 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
> 8) OpenID enabling patch for OpenSSL and PHP 5 > > 1 0 -1
0
> 9) Add array_replace[_recursive] functions (patch is already > available) > > 1 0 -1
0
> 10) Split off deprecation from E_STRICT into E_DEPRECATED > > 1 0 -1
+1 And 0 for the rest of them.

Mike Robinson

18 years ago
Since my vote counts for shyte, I'll humbly offer brief remarks instead. Ilia Alshanetsky queried:
> 6) Remove safe_mode, register_globals and magic_quotes > > 1 0 -1
*Major* BC break in a minor version? Ouch. This should wait I think.
> > 7) 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

Steph

18 years ago
Hi Mike,
>> 7) 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?
ouf.... PEAR is for PHP code, PECL is for C code. This is C code. It's also a *native* PHP driver, meaning it's faster than the libmysql library used currently for all MySQL-related extensions. The difference in build terms is simply a configure switch, and I don't see anyone recommending it should be mysqlnd by default at this stage. - Steph

Mike Robinson

18 years ago
Hey Steph, PECL, right. Ilia's initial post mentioned "possibly enabling them by default" which set off some red flags for me because it's very much alpha. It'd definitely help things along if it goes into the core, in terms of exposure / usage / testing. Best, Mike Robinson

Hannes Magnusson

18 years ago
On 9/9/07, Ilia Alshanetsky <ilia@prohost.org> wrote:
> 1) Backport the namespaces patch for PHP 6 > > 1 0 -1
+1
> > 2) 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
0
> > 3) Apply the Late Static Binding Patch > > 1 0 -1
+1
> > 4) Implement David's Circular Garbage collection patch > > 1 0 -1
+1
> > 5) Implement Sqlite3 support via the ext/sqlite extension (patch is > already available) > > 1 0 -1
+1
> > 6) 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)
> > 7) 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
> > 8) OpenID enabling patch for OpenSSL and PHP 5 > > 1 0 -1
+1
> > 9) Add array_replace[_recursive] functions (patch is already available) > > 1 0 -1
0
> > 10) Split off deprecation from E_STRICT into E_DEPRECATED > > 1 0 -1
+1
> > 11) Merge the zend_arg_info const'ify patch > > 1 0 -1
+1
> > 12) Merge the GCC 4 -fvisibility patch > > 1 0 -1
0
> > 13) Switch for disabling/enabling materialized cursors in mysqli > > 1 0 -1
+1 (wasn't this voted, and agreed, for for 5.2?)
> > 14) Link phar extension from PECL into core (possibly enabling it by > default) > > 1 0 -1
0
> > 15) Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch > > 1 0 -1
+1
> > 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? > "htaccess" style ini file support > > 1 0 -1
+1
> > 17) Merge __callStatic patch from PHP 6 > > 1 0 -1
0
> > 18) Introduce concept of "strict classes" that do not permit dynamic > property creation > > 1 0 -1
+1 -Hannes

Derick Rethans

18 years ago
On Sun, 9 Sep 2007, Ilia Alshanetsky wrote:
> 1) Backport the namespaces patch for PHP 6
-1
> 2) Symlink the intl extension from PECL, but leave it disabled by default as > is the case with all extensions dependent on external libs
1
> 3) Apply the Late Static Binding Patch
1
> 4) Implement David's Circular Garbage collection patch
1
> 5) Implement Sqlite3 support via the ext/sqlite extension (patch is already > available)
0
> 6) Remove safe_mode, register_globals and magic_quotes
-1
> 7) 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
> 8) OpenID enabling patch for OpenSSL and PHP 5
1
> 9) Add array_replace[_recursive] functions (patch is already available)
0
> 10) Split off deprecation from E_STRICT into E_DEPRECATED
1
> 11) Merge the zend_arg_info const'ify patch
0
> 12) Merge the GCC 4 -fvisibility patch
0
> 13) Switch for disabling/enabling materialized cursors in mysqli
0
> 14) Link phar extension from PECL into core (possibly enabling it by default)
0 for adding it to core, -1 to enable it by default
> 15) Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch
0
> 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? "htaccess" style > ini file support
0
> 17) Merge __callStatic patch from PHP 6
1
> 18) Introduce concept of "strict classes" that do not permit dynamic property > creation
1
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org