Up until today, I was really pumped up about the imminent release of PHP 5.1. Then I read [url=http://beeblex.com/lists/index.php/php.internals/17883]this[/url].
I'm still excited about 5.1, but it now pales in comparison to the potential that exists in 6.0.
The best part, though, is the general concensus of change that's attached to the thread.
Read on for my opinion on the points that have been brought up.
Let's take a look at Rasmus' original ideas:
[quote]1. Remove register_globals completely[/quote]
Yes! Anyone with half a clue agrees that register_globals shouldn't be used. Let's help those with a lower clue-ration.
[quote]2. Remove magic_quotes_*[/quote]
Yes! Same rule as #1. I [i]really[/i] hate cluttering up my (must-be-portable) code with stuff like "$var = get_magic_quotes_gpc() ? stripslashes($_GET['var']) : $_GET['var'];"
[quote]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.[/quote]
I was originally [i]against[/i] this idea. Well, more like [url=http://beeblex.com/lists/index.php/php.internals/14669]against automatic filtering[/url]. I've since changed mind.
One of the things that I had the opportunity to chat with Rasmus about at [url=http://blog.phpdoc.info/archives/11-Busy-Conf.-PHP-Quebec.html]Conf. PHP Quebec 2005[/url] was admin-implied input filtering. He told me that input filtering should be an option of the system administrator, and shouldn't always be left in the developer's hands. This makes sense. It's primarily the developer's burden to write good code, but most of us run apps that weren't written by [i]us[/i]. There should be some way to apply blanket filtering.
Obviously, to make this system work, there needs to be some way for the developer to access the raw, unfiltered content (yes, there ARE occasions where it's necessary to grab '<', '="">', and '"' from the request. My retort to Rasmus' theory of admin power was "If the developer can get to the raw data (and he [i]has[/i] to be able to do this), how are we any better off? Yes, a good developer will use this mechanism ONLY when necessary, but what about a Jr. developer who 'learns' from the wrong piece of code?" His answer: it'll be simple to grep for this mechanism. So, I conceded. I'm now all-[i]for[/i] an automatic input filter.
[quote]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.[/quote]
Zend politics aside, I don't know why this hasn't been pushed harder before. +1
[quote]5. Remove safe_mode and focus on open_basedir[/quote]
I've never had the.. uh.. "pleasure" of working with safe_mode, professionally, but this SEEMS like the best option. Yes, it will upset a LOT of web hosts. Hopefully they'll see the light. I'm not holding my breath, though.
[quote]6. Remove some stuff that has been marked deprecated since PHP 3/4[/quote]
Please, yes. With the exception of dl() (-:
[quote]7. Make identifiers case-sensitive
8. Remove various function aliases[/quote]
These, I don't really care about. Either way is fine by me.
So there's my 2c (Canadian).
What do [i]you[/i] think?
S
These are defintely some excellent suggestions and will be a great improvement for PHP. My question is though, is this it? Surely PHP 6 is not just going to be about Unicode support and tidying up some of PHP uglier parts. If you look at all the cool stuff added to PHP in version 5 isn't PHP 6 going to have more of the same scale improvements. I know its still early days for PHP 6 development so I'm just curious what else might be on the cards.
Just Unicode? There is nothing "Just" about Unicode.
Ok, why is Unicode a big deal then? I'm not too familiar with it.
PHP is moving on towards gearing itself for PHP 6.0. Andrei started warning people to not commit to HEAD as he was about to start committing his Unicode support for PHP. He mentions in his blog post: The project that...
Unicode is what php lacked for ages. Its a great improvement but i would also like to see some more improvements to the OO part, to make it even more like other OO languages.
Some more things might be improvements to PDO
like to see a more enterprise bent - namespaces, templating, threads, messaging, more towards porting php to .net and java for seems interoperability between the two - gluecode for the web ( i know Perl ). Ruby on Rails model for quick MVC creation
[QUOTE]I really hate cluttering up my (must-be-portable) code with stuff like "$var = get_magic_quotes_gpc() ? stripslashes($_GET['var']) : $_GET['var'];"[/QUOTE]
So why not just use ini_set('magic_quotes_gpc',false);? Don't test for it every time you need a request parameter, just switch the damn thing off before you start coding!
you've obviously never actually DONE this.
by the time your code (the ini_set line) executes, PHP has already run the mechanism that takes requests and puts them in the variables.. so, your little trick has no effect.
S
Sorry, my fault. I meant php_value in the .htaccess file (on apache). I use lighttpd and build php manually, so always switch it off in the ini.
Yes. I do this as well in environments I control..
however, to write portable code, or code that works in a "dirty" environment, you need to check magic_quotes_gpc.
S