Rasmus Lerdorf wrote:
Since we are breaking a lot of stuff in 6.0, at least with
Unicode_semantics=On I am wondering if it may not be time to break some
+100 for Unicode support
1. Remove register_globals completely
+1
2. Remove magic_quotes_*
+100 (any "magic" is bad in the long run, see Perl)
3. Add input filter extension which will include a mechanism for
application developers to very easily turn it off which would swap
the raw GPC arrays back in case the site had it turned on by default.
+0
4. Include an opcode cache by default. A lot of work has gone into
pecl/apc recently, but I am not hung up on which one goes in.
5. Remove safe_mode and focus on open_basedir
+0.5 I think that safe_mode and similar kludges and hinges really
shouldn't be in any language. OS needs to provide the security we
need, it cannot *safely* be added at some higher level.
As what to comes to renaming old function I don't like it. I've been
hit with minor stuff like changing pgsql_numrows to pgsql_num_rows()
in a minor release and even though there's an easy fix, it still not
worth it. If you want to fix not-so-well named functions like
in_array() or strstr() put the fixed functions in a new namespace or
add a suffix like, for example, 2. So PHP6 could have
strpos(haystack,needle)
strpos2(needle,haystack)
str:pos(needle,haystack)
str::pos(needle,haystack)
or some combination of above, but PHP6 *should not* have
strpos(needle,haystack).
If I were to decide, I would move all the old functions to new names
into new namespaces and include a wrapper files with public domain
license so that it could be freely modified as required. The PD
licensed files contained just code like
compatibility/str.php:
....
function strpos(haystack,needle)
{
return str::pos(needle,haystack);
}
....
and the old code that required the old functions could just add
require_once("compatibility/str.php"); in required files. That is,
rename the functions as seen best and provide compatibility code in
user space to make the old code work without big changes.
In addition, I'd change following:
* Handle incoming parameters and data better. According to HTTP
specification, an URL can contains stuff like
"...foo=1&foo=2&foo=3..." and I should be able to extract those
values without having "[]" in every parameter name. See <select
multiple> or <input type="file">, for example. I'd prefer "array
query_param(param_name,method)" which returned an array of values
for parameter named according to param_name. The optional method
parameter is used to select GET, POST, DELETE, PUT or whatever. By
default method would be ANY which would be interpreted as
GET,POST,PUT,DELETE,COOKIE meaning return stuff sent with GET
protocol first, followed by stuff sent by POST protocol and so on. I
think GET should be used first because it's easiest to change. It is
*not* a security feature to use COOKIE first because it can be
modified almost as easily as GET. Debugging and workarounding
different bugs is just harder if GET doesn't override values set by
other means.
* Improved file uploads. Make it possible for a PHP script to
decline an upload *before* it has been completed. Make it possible
to handle *big* uploads without requiring uploaded file to fit the
memory. Handle multiple file uploads with the same name better than
now. $_FILES['fieldname'][1]['filename'] if far from a good solution
and even that works only if field is really named "fieldname[]".
* Better error reporting. As I cannot capture ALL errors (including
parse errors and friends) with user defined error handlers I need
*much* better error messages to system log by default. At least
exact time (perhaps down to microsecond?), back trace, error
location (and in case it was eval()ed code, the location of eval()
call - or locations of eval() calls if they were nested) would be
required in addition to currently logged information.
* Anonymous functions. The real stuff, not just some odd string
passed to create_function().
--
Mikko
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
