Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:18249
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <4309DC9B.8020904@peda.net>
Date: Mon, 22 Aug 2005 17:09:31 +0300
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
MIME-Version: 1.0
To: internals@lists.php.net
References: <42FCE0E4.604@lerdorf.com>
In-Reply-To: <42FCE0E4.604@lerdorf.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: PHP 6.0 Wishlist
From: mikko.rantalainen@peda.net (Mikko Rantalainen)

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