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 [EMAIL PROTECTED] 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
