Hello Mikko,
Monday, August 22, 2005, 4:09:31 PM, you wrote:
> 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.
Read the docs and look for the upcoming input filtering.
> * 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[]".
You can always grep the names, you can always access the raw data and well
early declining would require some more interaction with the sapi. So you'd
first need to contact the sapi wroters or find out whetehr that is possible
at all. The we'd need to find out how to handle that. In theory you have now
two threads, hmmm.
> * 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.
At least apache should be able to write microseconds, on windows system sthe
problem would be the resolution of the internal time which is ~10ms. And an
E_PARSE will never be catchable by a PHP script.
> * Anonymous functions. The real stuff, not just some odd string
> passed to create_function().
There were some others already asking for this, maybe we should at least
give it a thought if it is doable at all, anybody?
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
