PHP 6.0 Wishlist

On Fri, 12 Aug 2005, Rasmus Lerdorf wrote:

+1

+1

+1

+1

+1 (I'd say remove both though ;-)

+1

You mean: make *all* identifiers case-sensitive? (Currently varnames are already case-sensitive). If you meant all: +1

+1 Derick

On Aug 12, 2005, at 10:48 AM, Rasmus Lerdorf wrote:

Yes.

Yes. Nothing but trouble, this one.

Yes.

Emphatically yes.

Yes.

I don't have an exact list of this, but yes.

I've already stuck my neck out on this one a couple of times, and haven't gotten much traction, but sure..

Could be nice to clean up. -Andrei

Rasmus Lerdorf wrote:

+1

+1

+1 As long as swapping for raw takes no more then a function call per input type, ala restore_input(PHP_GET).

+1 As long as it does not prevent alternate solutions from being used.

+1

Let's do this on a case by case basis, perhaps make a list of all deprecated items and vote on them individually.

That closely relates to 6, so same comments apply. Ilia

Rasmus Lerdorf wrote:

Yes please :-) That'd remove half my admin headaches from shared boxes.

I'm not sure if it should be turned on by default - maybe ini settable. Personally, I've come up against a number of issues with apc & session support and wouldn't really trust developing in an environment with an opcode cache turned on. No real opinion on the rest though. Would make sense for any api changes for modules to be pushed through in the same release though as well, as we're going to have to change our modules for unicode support anyway.

I agree on all points. Case sensitivity would be nice IMO, but I can continue to live without it. --Wez. On 8/12/05, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

On Aug 12, 2005, at 1:48 PM, Rasmus Lerdorf wrote:

+1

+1

That seems a bit scary, and almost as if it would defeat the purpose. I'm all for an input filter extension, but it should be one that can't be easily neutered by (potentially malicious) applications.

+1

+1. I agree with Ilia that this should be done on a case-by-case basis.

+1 9. Radically change all the operator syntaxes. Oh wait, that's Perl 6.0, sorry. George

+1 to all things here. -Sterling On 8/12/05, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

Rasmus Lerdorf schrieb:

+1

+1

+1

+1

+1

+1

+1

Hello, +1 to all things, same comment as the opcode cache Ilia's one. I would like to add one from my wishes: Bump version for the required library as high as possible (or realist) and do not support museum softwares at all, like droping freetype v1 for example. Most of the users do not use it anymore, but it will make the whole much more clean and easier to maintain. --Pierre

I would like to add item #9: * start commenting the code, plz * As long as we don't have any documentation describing internals, comments in the code are something I personally would _really_ like to see. And the more the better. On Fri, 12 Aug 2005 10:48:20 -0700 Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

+1 to all of these. I have a #9 to share, too: Assuming that PHP 6.0 will also have namespaces support (which would be cool), it might make sense to move all internal functions to use namespaces (if they support functions sitting in there - doesn't seem like Jessie's current patch will, but then, maybe there's a chance). That way, we could clean up naming inconsistencies (think of all the str* functions), and maybe even some of the common annoyances when it comes to parameter order (haystack, needle vs. needle, haystack) Just a thought. - David

As little as it means, +1 - Davey Rasmus Lerdorf wrote:

Amen! +1

Hallelujiah! +1

Eh... +0

Okay... +0

+1 on dropping safe_mode, and here's a thought for open_basedir. I was thinking about a comment made in another thread... how about open_basedir_child(bool). When enabled, only files at or below the directory in which the current script is executed from may be opened. There may be some SAPIs where this is problematic (since we may not know what directory the file is opened from reliably), but it's worth looking into.

Praise non-denominational-diety! +1 Though my definition of "remove" would actually be "migrate to siberia". Whole modules where appropriate. "deprecation" collections where not.

Or perhaps optionally case sensitive? I dunno, I've made my peace with PHP being (mostly) case-insensitive.

Many of these fall under #6 honestly. I can think of a few that can fall by the wayside. #9... No.... must...resist....four-letter-token....can-of-worms....mmmmggmhghmhhmmhgmhmgm mmm * otherbird sneaks up behind Sara and clamps her mouth shut before the genie is released.

Rasmus Lerdorf wrote: [lots of reasonable points] What about moving some/many extensions from core to pecl? Regards, Mike

I have no karma to +1, but would if I could. It would be wonderful if something like xdebug could profile with op code cache on as well, should it be possible. :) -steve--

Now I'm not the person with the kind of karma that should make you guys listen, but in case you are interested, I'll just add my 2 cents

+1

+1000

+1

+1 Althought perhaps it could remain case-insensitive, but throwing a notice. This way users can decide for themselves if they wanna write neat code by using E_ALL. On the other hand, I assume case sensitivity would improve overall performance, while notices do the exact opposite.

+1

Might I add a few requests: 9. Much improved __toString behavior (I doubt I'd need to clarify that) 10. Broader support for (custom) stream-wrappers (I noticed the zlib functions don't accept them). I wanted to make a stream wrapper for strings, so I could do this: readgzfile("str://andHereSomeGzipData").. In fact, if you ask me, such a str:// wrapper may be implemented as a standard wrapper. It would be useful in a lot more cases where functions read from files. 11. Altered/improved garbage collection (see my recent post on leaking memory when throwing exceptions from a foreach() loop). Leaking memory may be perfectly fine in a webserver situation, but I personally use PHP a lot for cli-scripts (sometimes forever-running daemon applications) and I'm sure a lot of other people do as well. 12. I hate to bring this up, don't shoot me for this, but ... multiple inheritance? ;) 13. A built-in code optimizer. Why should something like Zend optimizer be installed afterwards, if everybody can use increased performance? 14. Turn (all) fatal errors in extentions and the core into exceptions. Personally, I'd like to be able to catch and log all error situations, not just the ones I create myself. The exceptions should be of a specific custom exception class of course. If people don't catch the exceptions, the output would be pretty much as the same as fatal errors are right now anyway, so BC won't really be a problem. 15. Remove $HTTP_* (altho you may have included that when you thought of #6) and register_long_arrays. 16. Support for <?php="foo" ?> 17. A reliable non-bankers-round function 18. The ability to use an array() of constants in a define. Maybe I'll think of more later ;) Ron

On Fri, 12 Aug 2005, Rasmus Lerdorf wrote:

+1 (then we can cleanup the mess in ext/session too :)

+1 (definately, finally, at last! The filter stuff obsoletes those anyway?)

+1 (to be able to do 2. for real, of course)

+100 (it's ridiculous to have to install it separately)

+1

Something like 'allow_call_time_pass_reference' or whatever it was again?

Such as function names? :) That'd be kinda nice since it not only makes the language more consistent but also tad faster, especially now with the unicode stuff slowing that down even more..

I was toying with an idea about a configure switch and/or ini option. But I guess some of those just should go away. The other wild idea I got while thinking about this was to add opposite option for 'disable_functions', 'enable_functions', which would only enable the functions I _really_ use :) --Jani

+1 from here too except 0 for the case sensitivity. Andrey Rasmus Lerdorf wrote:

+1 on all the mentioned items, except for case sensitivity for identifiers where I am -1 (I dont see the benefit). Aside from that I wouldnt mind an aggressive function name and parameter order clean up. We could provide a BC lib via runkit (or was it classkit .. I can never separate the two in my brain). Speaking of *kit .. how about sandboxing or some sort of taint model. regards, Lukas

Hello Rasmus, Friday, August 12, 2005, 7:48:20 PM, you wrote:

+1

+1

+1

+1

+1

+1

+10

~0

Very nice list. Very nice list. May i continue with a few additions of mine by order of importance? 9. __toString) everywhere, but i already said i'll take care of that unless i am being held back. So now go for that or live with the fact that php is meant to generate html pages which is text output. Thus sooner or later your objects create text simplifying that aas much as possible is at least to me mor ethan welcome. 10. namespace support (we are telling everyone php is ready for the big soup. In those scenarios you often find big teams and any help allowing things like dedicated responisbilities and preventing communication problems is more then welcome.) 11. class operator cleanup :: static -> non static this would allow to do more things like accessing static members/consts from anywhere a class is allowed etc. (if proposed that before incl. patch lookup the archieves). 12. {} vs [] cleanup 12a. using {} for strings could also bring us substr() functionality to {}. 13. eventually cleanup parameter order. Guys who knows in which functions the needle is first or second? My solution is to look up every function always which is a bit inefficient. I know the param order in c/C++ and sometimes in java but in php storing that info is impossible and useless so far. 14. i read drop gd1, nice one 15. i think of splitting dba, making ini-file into dba core and putting all but dba core into pecl (further plans for ini-file). 16. changing var_dump() et all to write out the class name for members since it is not helpfull at all if you see two members of the same name. Maybe it helps if one is private and the is not but still .... And i already treated "the operator which must not be named" for somethig else so there is no 17 here. Wow you made it till here. My favorites are actually: 7, 4, 3, 9, 10, 11, 1, 2, 5, 6, 12, 13, 14,15, 16 I consider most of the above actually as bugs: "Whipe them out *all* of them". Best regards, Marcus

+1 bundling the opcode cache like APC. I also wish some elemental debugging features (stack dump, etc.) like Xdebug has. Rui On Fri, 12 Aug 2005 10:48:20 -0700 Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

Hi

+1 to all things here. 9. Shared memory storage for variables with transparent access. (superglobal array?)

Rasmus Lerdorf wrote:

Big +1 9. Named parameters. Preferred way would be via array()-less array collation as we are already using this in our production system ;-) : foo('id' => 42, 'name' => "foo"); 10. Allow dangling commas in function calls, handy with varargs and 9: foo(1, 2, 3,); Minor: 11. HTTP response splitting attack protection: Replace \r and \n with space in header(); Information and patches implementing this can be found at http://cschneid.com/php/ - Chris

Hi, On Fri, 12 Aug 2005 10:48:20 -0700, in php.internals rasmus@lerdorf.com (Rasmus Lerdorf) wrote:

I know this is just a wish list, and it wouldn't be constructive to go into implementation details. As you said, this is cleanup where some eggs will have to break. FWIW, as many others, I'm mainly positive about all the changes. Not surprisingly there would be a bunch of work regarding the information to end users. This might require some political decisions on what to recommend, when "features" are removed from users. I'll go into details here:

I'm all for. It would be nice, though, to provide users with details on how to do it "the right way" regarding database queries. Even though there are a lot of ways of doing it (manually call mysql_real_escape_string, use PEAR DB, use another API, etc.)., it might be nice to show users a simple way of doing stuff. I really like the perl DBI which is the de facto way of doing database work. I believe that lots of stuff that DBI (and PEAR DB and other DB abstraction layers) provide is helpful. Crafting and concatenating a query string really is a mess. On one hand this might have nothing to do with the tools and more on recommendations on how to code. It might not be the job of the PHP team to teach users how to code or recommend specific ways to code (think of all the OOP- and exception handling-discussions). Furthermore people might have different views on what API to use. I like PEAR DB because it is widely used, but as an example I don't like the chicken-and-the-egg problem (DB_common only gets read when DB::Connect has been called and loaded, så DB_common can't be extended). The point is mainly that it would be hard to recommend one way of doing things now (and it might be a political decision as well). On the other hand, people will be in demand of "how-to-convert"-information in the transitional phase. And if we really are doing a spring cleanup, we might consider doing it on the users as well :-)

This might go in hand with the first two wishes. It would be nice to make it easy for users who write php code that are going to be distributed world wide on different configurations without going into hundreds of different checks (such as "if (get_magic_quotes_gpc()) { .. }" ).

I think a lot of work would have to go into this. Currently <warning type="pet peeve"> it could partially be circumvented using glob, e.g. print_r(glob("{/home/currentuser/,/etc}/*",GLOB_BRACE)); or error harvesting ("File(/tmp/sess_1234567890) is not within the allowed path(s)") </warning> I'm not sure whether or not this is regarded as a problem. These issues have been dismissed on the bugs list and I haven't heard anything from security@. Another type of default session handler might also be nice without direct mapping of file names and session ids - e.g. hashed values and addition of hashed SERVER_NAME where available. Regarding the way users code (as mentioned in #3), we also see that when notices were enabed and widespread on installations, e.g.: if ($_REQUEST['foo'] == ...) .. users just changed their code to: if (isset($_REQUEST['foo']) && $_REQUEST['foo'] == ...) I don't think this is particular more nice code, but just a recurring pattern every time a variable from the outside is submitted. This is a really wild idea, but how about retrieving external variables using functions instead? The idea is that external data isn't variables per default and could be referenced without throwing notices, e.g.: if (getuserdata('foo') == ...) Of course I'm not against notices, but I think there is a clear distinction (or should be...) between stuff that might exist beyond our control (user-submitted data) and stuff that we rely on (own variables). But all in all: very exciting. As mentioned, there really might be a lot of work regarding the information and transitional help if all these wishes come true.

for what its worth - brilliant :-) aftering reading the remarks about perl6 (love the idea of you guys winning that 'race' :-) I did a little reading, seems perl6 is aimed to target Parrot... I remember there was discussion about this for php, don't know if the idea died a lonely death or was just put in the deepfreeze - maybe it's something to consider? Rasmus Lerdorf wrote:

Rasmus Lerdorf wrote:

How about allowing mod_php6 to run alongside mod_php? Provide an easy way for the hosting people to provide PHP6 without breaking everything. Aaron

At 20:48 12/08/2005, Rasmus Lerdorf wrote:

First of all, in general - I don't subscribe to the school of 'we broke something, why not break more'. With every feature we break, we reduce the chances of people upgrading, of legacy apps working, and we reduce the overall success chances of the new version. Compatibility breakup is not binary, it accumulates. The more features are broken, the worse the situation becomes.

Given what I said above, I don't see any motivation to remove register_globals or magic_quotes. I don't see how it buys us anything other than pissed off users and hordes of (sometimes exploitable) bugs that will result from sloppy audits. These changes alone would mean that a great deal of the applications would have to be 100% audited before an upgrade. Between us, developers welcoming forced labor due to upgrades is wishful thinking. People never like to be forced to go over their or other people's code regardless of the circumstances. If we are to do anything about register_globals, perhaps we can change the name of the directive to something else (e.g. unprotected_globals), and of course keep its default 0. Admins will have to make an informed decision to turn it on again, and we can speak against it as strongly as we want in an upgrade guide. Change the default of magic_quotes_gpc to 0 as well.

Sounds good.

Need to think about that one.

Sounds good.

As I'm sure you'd agree, academic purity is not exactly why PHP won the hearts of the masses. I would almost argue the opposite. Features which only bother us due to academic purity are clearly ones we shouldn't touch. Even more so than register_globals and magic_quotes - which are not only impure but also problematic - there's no point forcing people to modify their code just because we feel like making PHP more academically pure. Other than creating a huge worldwide mess and slowing down migration, we're not going to gain anything (assuming we don't get any points for academic purity; PHP scored 100 when handed in as an academic project, by the way :). Even if we forget about the users, and only think about ourselves - unless something drastic happens, we're going to look at supporting 4 major different versions simultaneously - 4.3/4.4, 5.0, 5.1 and 6.0. Is it really such a great idea to start breaking compatibility beyond what we absolutely have to? I think you have some good ideas in that list, and some less good ideas. I'm worried about the wholesale mode that internals@ switched into, the almost unanimous "YES!" response, and the overall feeling that suddenly with 6.0 breakage comes without a price. That goes counter to our key design goals in the Unicode support, which were work-as-if-nothing-happened when unicode support is disabled. Zeev

Just my 2 cents : 9. I don't know current status of apache_hooks (http://cvs.php.net/php-src/sapi/apache_hooks/) but it would be nice to make it stable with good documentation on php.net 10. make standarts for function's names. For example php has str_replace() and strpos(). I think last function should be named str_pos(). But if namespaces will be added to internal functions (str:replace, str:pos) it will be unnesseccary. 11. +1 namespaces 12. disable @ via settings 13. add keyword 'finally' to exceptions Rasmus Lerdorf :

On Aug 12, 2005, at 1:48 PM, Rasmus Lerdorf wrote:

This is a sweet carrot to drive adoption despite a few minor BC issues.

Rasmus Lerdorf wrote:

+100 for Unicode support

+1

+100 (any "magic" is bad in the long run, see Perl)

+0

+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().

Hi: It would be nice if PHP could not get tripped up by "<?xml" tags when short_tags is on. http://bugs.php.net/bug.php?id=25987 --Dan

It's unclear to me what the position of the big kahuna's is on the following issues, but I hope they can become a reality in PHP6: 1) named parameters. in user functions, but also in core functions: $result = in_array(needle: "foo", haystack: $array); 2) error reporting using exceptions. I would like it if I could catch PHP-errors and take appropriate action (such as logging it to a database or whatever). 3) doubling the precision of integers to 64 bits and floats to 128 bits. I know Wez wants this too, but will it happen? I think it would be nice if it would be a transparant change and the standard types would simply have a bigger range. 4) improved __toString behavior 5) Altered/improved garbage collection (see my recent post on leaking memory when throwing exceptions from a foreach() loop). Leaking memory may be perfectly fine in a webserver situation, but I personally use PHP a lot for cli-scripts (sometimes forever-running daemon applications). 6) Broader support for (custom) stream-wrappers (I noticed the zlib functions don't accept them). I wanted to make a stream wrapper for strings, so I could do this: readgzfile("str://andHereSomeGzipData").. In fact, if you ask me, such a str:// wrapper may be implemented as a standard wrapper. It would be useful in a lot more cases where functions read from files. Thanks, Ron

The wishlist on PHP6 has grown a lot last weeks. Here is what I have missed so far: switchable behaviours in php.ini file: - enforced variable initialisation (throw E_ERROR where today E_NOTICE is triggered) - strict variable typing (This can be done with SetType already, but a nicer language construct as in other languages (I do not say "C" or "java" ;) would be nice) - automatic type conversions on|off And also I would like to see type checking on function parameters for simple types as "integer", "string" etc... Only having this for classes is not strict enough. Also an useful feature would be "const" on function parameters. just my €0.01 mike

Rasmus Lerdorf schrieb:

In case we include APC by default, it would be nice if its apc_store() / apc_fetch() mechanism could be mapped to a new super-global, say $_PERSISTENT[].