Slashdot Mirror
PHP 6 and What to Expect
An anonymous reader writes "Jero has a few interesting thoughts on what PHP 6 is driving towards and provides a nice overview of what has been keeping the PHP team busy lately. For more specifics, PHP.net also has the developers meeting minutes from last November available with a great recap of all the major issues on their platter."
My suggested change would be to go back to the GPL instead of the crap PHP license.
Since jero.net already seems to be /.ed...
Taking a look at PHP 6
While most web hosts are still in the PHP 4 era, the PHP developers are already planning and working on PHP 6. Lets have a look at whats been keeping them busy.
Unicode support
When youre creating a website, you hardly have to think about the character encoding. You only have to decide how you tell the user agent what encoding youre using, but with a little help of Apaches .htaccess file, you only have to make that decision once. However, if youre building an application, the character encoding might become a problem. Thats where PHPs new Unicode support comes in handy. With its support, PHP can automatically encode and decode the in and output of the script making sure both the database and the user agent receive the encoding they need without the need of any extra functions for the encoding conversion.
The big cleanup
PHP is already being used for a long time, creating a big user base, but also a lot of bad habits. Bad habits often result in slow scripts or even security holes. But these bad habits are not always the cause of the developer. Of course, he (lets just assume were dealing with a stereotype developer here for simplicity's sake) is the one whos using it in his application, but sometimes the developer is not even aware hes using it.
Im, of course, talking about the register_globals , magic_quotes and safe_mode functions. These three functions are hell for every PHP programmer so Im sure everyone will be happy to hear that these functions will disappear in PHP 6.
In other related cleanup news, register_long_arrays and the long versions of the super globals like $HTTP_COOKIE_VARS are also gone in PHP 6. Same goes for zend.ze1_compatibility_mode which dealt with the backwards compatibility of PHP 5 classes.
Alternative PHP Cache
Caching is a very good way to improve the performance of an application. Thats why there was a large demand for a good opcode cache in the default distribution of PHP. And when theres a demand, theres probably also a person or a group to meet that demand. The result is APC: Alternative PHP Cache. Of course, APC was already available a long time ago (01-07-2003), but the PHP developers have decided to include this extension in the core as the default caching framework.
OO Functionality
The improved OO model was probably the biggest improvement to PHP in version 5.0. PHP 6 tries to improve this even further by adding namespaces. If youre familiar with XMLs namespaces or maybe C++, you will probably have an idea of how namespaces work. If not: Namespaces can group variables, functions or objects under a certain name. This allows the developer to use the same name for a variable, function or object multiple times. In case youd like to learn more about the possibilities of namespaces, I find this C++ tutorial about namespaces quite useful.
Changes to the extensions
PHP is basically a collection of extensions which are all put together to form what we have now. However, these extensions change and so does the collection. Take, for instance, the XML Writer extension. A great extension to write XML files. Its brother, XML Reader, was already added and enabled in the core distribution in PHP 5.1, and now XML Writer will follow its example in PHP 6, forming a great duo to easily work with XML files.
Another change in the core distribution is the removal of the ereg regular expressions library which is going to be made an extension. ereg is currently used
Gan Family Homepage
I wonder if most of the new features in PHP 6 will even appeal to most users. I started on PHP 4 with O'Reilly's Programming PHP and when PHP 5 came along, I didn't notice anything that was really missing. It's like Perl 6, there are already plenty of people who feel that what they have so far serves their needs, and there's not anything to improve upon.
It'd be great if variables, functions, classes, and constants could be defined in their own namespaces. For really big projects, it's too easy for names to collide in the global namespace. An annoying workaround has always been to make names unique by prepending them with something.
"There is no spoon." - The Matrix
Funyn thing is, in the digg dicussion on php6, most of the people were upset at how much rewriting they'd have to do without register globals or magic quotes! bwahahaha!
Do you even lift?
These aren't the 'roids you're looking for.
There still isn't wide-spread use of PHP5; why move onto PHP6?
Either not enough people think PHP5 is suitable to their needs (and requires more work), or there isn't enough reason to switch from PHP4 to PHP5.
Either way, it seems that working on PHP6 isn't necessary at the current time.
phpBB, vBulletin, mysqladmin, postnuke, phpDiplomacy (shameless self promotion), etc, etc; none will work until they've been ported to the new PHP5 OO model, and once they've been ported they won't work on PHP4.
They should leave in backwards compatibility for the class based OO model which <PHP5 uses. Once they bring out PHP6, PHP5 will be the only version which runs new and legacy PHP scripts, so PHP5 will clearly become the standard for a long time.
I'm a big fan of PHP, but with so many apps (e.g. my university's timetabling app) still in PHP3, all the rest in PHP4, both becoming obsolete, changes to the API, even changes to what's allowed within the same version; I'm starting to wonder if I should have focused on a more stable language like python or perl instead.
// MD_Update(&m,buf,j);
He said, sheepishly.
"Speaking the Truth in times of universal deceit is a revolutionary act." -- George Orwell
The argument why .PHP is seen as being less of a programming language to .NET is its lack of framework support.
.PHP being not quite enough agaisnt competeing solutions.
.PHP hardcore users v5 is really quite nice it does allow for more sparing use of memory and allows for a bit more OO functionality but at the end of the day to make .PHP a usable piece of enterprise software it needs to have a mature framework.
.PHP will be left to catch up.
They should finish working on PEAR and getting it properly documented along with getting most of the respoitory packages out of "alpha" release. Then we wont have this stigma about
Its good to see that they want to "fine tune" php and they are discussing the important programming syntax elements of the langauge, but like everyone else is saying why move to v5 in the first place? Well for those
Otherwise I presonally believe we'll start seeing Ruby hit the scene a bit more and
This would be really great!!!
Seriously though, apart from its popularity, is there any reason to choose PHP over the multitude of other existing solutions?
more non-type-safe, unstructured, convoluted crap for the unwashed...
Admittedly, I didn't RTFA, but 'goto' is almost definite to be included in PHP6 upon release. Do we really need this pandering to the VB migration crowd, sacrificing code structure for the sake of a bigger PHP userbase?
xkcdsw: the unofficial archive of Making xkcd Slightly Worse
No, seriously. PHP has accumulated a lot of broken things over the years, and it is hurting it. This new version of PHP should be turned into a whole new language entirely, or made incompatible with older versions (like Perl 6 is doing). Reasons:
PHP's design is fucked up. Some functions have underscores, others don't; some have numbers, others don't: strtolower, isset, stripslashes compared with hex2bin, is_null and strip_tags to name a few. Why? Who knows? But too many applications rely on these inconsistencies, and making them consistent would break everything.
It has no namespaces. Luckily, they are to be added in PHP 6 (and about time too!), so we can do $db::connect() rather than mysql_connect($db). So can we get rid of all the mysql_* and other pseudo-namespace functions please? They are annoying and will be wholly unnecessary.
Security problems. Register_globals and magic_quotes are still built into PHP when they should be built out and as far away from it as possible (and they are!). There are going to be people who will wonder why this upgrade breaks those things, and people should know that a new language does things differently. (Likewise: Perl 6's given/when block isn't called switch/case because it behaves differently).
Now that I've typed all that, much of my reasoning is that people rely on PHP's being bad. People should never rely on poor language design, or bugs, or bloat, of which PHP has loads. The language should work, you shouldn't need to work around the language - and if you do, you're going to have a lot of trouble rewriting your code.
There might be little incentive to switch away from older versions of PHP for some people, but a few refinements of the language won't change that. "Better than PHP" would actually be true. "Made from the PHP team" would be a major selling point too.
I know that it's a bit risky saying this here (there seem to be a lot of people who like PHP for some reason), but a serious redesign is in order, and it's more than just a simple bumping up of the version number can fix.
Guy asked me for a quarter for a cup of coffee. So I bit him.
I have yet to see a major web host that offers Python Server Pages support which just so happens to be a standard feature of mod_python. The single biggest reason why PHP is so popular is that it is a free alternative to ASP with a modestly lower learning curve. Not to troll, but I'd like to make a bet here. If web hosts made inline Python, Ruby and Perl modules like mod_python availible to their users, few people would choose PHP over those three. The hardcore would choose Perl Server Pages, the uber-geeks would choose Ruby Server Pages and the rest would, rationally, choose Python Server Pages.
It's a pity they decided in favor of APC and not eAccelerator (the successor of turck mmcache), which is a lot faster in my experience.
Honestly, the way some of you bitches bitch anyone would think that PHP6 is a step backwards rather than forwards. I can't really see anything wrong with the language maturing. If it brings it more inline with some peoples definition of a "proper" language, then that's surely something to be commended - right?. Sure some of the updates are a bit late, but I'd hazard a guess that this is so due to purely pragmatic reasons, which y'know, is something that we can all appreciate in a way.
One thing I'm really looking forwards to is the native Caching and UTF-8 support (missing from Ruby).
--
Tokamoka
I don't understand why he's been modded down for this post. The website it came from is (at least partially) inaccessable, and it saved me a trip to google's cache, for which I am very thankful.
Sometimes I wonder if slashdot moderators don't go around and look at posts saying, "yeah... yeah, that one's a post other's would like to read... -1 Offtopic... heh heh... I just modded a good post bad... heh heh... I feel better about myself now..." *rolls eyes*
Mod this post all the way down to hell if you want. I got karma to burn.
FanFictionRecs.net
to make PHP strong typed!!
Nobody has pointed out the biggest problem with PHP5, and it doesn't appear to be addressed in PHP6: Exception handling.
PHP5 came with exception handling like that found in most mature object oriented languages, but the problem is that most PHP functions do not use exceptions, they simply return false.
This makes it difficult to use exception handling at all, because you have to mix the old way and the new way if you want to leverage PHP's huge library of functions.
I think the solution would be to implement standard exception behavior for all of the old libraries and add a setting in php.ini to turn the behavior on or off.
It's easy to write a PHP script that will fail without throwing an exception or returning a boolean value that can be handled. This makes PHP very difficult to use if you need your code to be very robust and solid. I've resorted to using classes and putting some code in the destructor to clean up if the script terminates unexpectedly, but this is ugly and should be something that one can handle by enclosing the error-prone logic in a try/catch block.
Needless to say, this problem isn't always a major issue for websites, but if you're doing anything more complicated than simple db lookups and printing HTML, robustness matters and PHP's shortcomings really stand out.
Partially due to this problem I recently switched a fairly large project to Ruby on Rails and have been EXTREMELY pleased with how fast development has progressed. I was able to reproduce 2 months of PHP development in rails in 2 weeks, learning curve included. Ruby is a joy to program with, way easier than PHP, C#, Python, etc.
Amazing magic tricks
phpDiplomacy (shameless self promotion)
I'm a big fan of PHP
You must be, you named your application after it.
Since I've never spoken to the developer of any other php* app, let me ask you something: Why on earth did you name your software after the language you wrote it in? What happens if you later decide to port your app to Perl or Ruby?
This is common for PHP devs for some reason, yet you never see it anywhere else. I heard Rasmus Lerdof speak a few years ago and he expressed his puzzlement (and annoyance) at this phenomenon.
Web consulting +
I had a lot of trouble when I was setting up a website at work because PHP was the wrong version. I hope that this new one doesn't cause any issues with the existing WAMP configuration(or LAMP for that matter).
EpiAdv - if you like Pokey the Penguin, try this comic!
I have yet to see a major web host that offers Python Server Pages support
Possibly because the abbreviation is already overloaded. As the developer of Luminesweeper, a clone of a PlayStation Portable flagship title, puts it: "Where I come from, PSP is still Corel Paint Shop Pro."
I still can't understand why PEAR doesn't get the same user contributable documentation system that PHP uses! Time and time again I've tried to use a new PEAR module only to be completely befuddled with the lack of examples and documentation. IMHO, PEAR usage would grow substantially if the docs were better. Don't get me wrong, the folks who have put the code up are great, and they do try; however, it's an uphill battle. It's just so much easier if end-users could chip in with the docs. And yes, I have mentioned this on a forum or a bug tracker or something --- 3 years ago.
Check out this recent article by Harry Fuecks.
From the article: "PHP UTF-8 is intended to make it possible to handle UTF-8 encoded strings in PHP, without requiring the mbstring extension (although it uses mbstring if it's available). In short, it provides versions of PHP's string functions (pretty much everything you'll find on this list), prefixed with utf_ and aware of UTF-8 encoding (that 1character >= 1 byte). It also gives you some tools to help check UTF-8 strings for "well formedness", strip bad sequences and some "ASCII helpers"."
Steve Magruder, Metro Foodist
If you're worried about use of undeclared variables, this is not impossible to detect, though slightly more complicated than "use strict".. set the error level to E_NOTICE and set up a custom error handler to throw an exception (or abort) when it gets called with the uninitialized variable code. (You could also set it to simply log a warning somewhere, as it is possible, and useful, in some cases to rely on uninitialized==false..) (I know its not one line.. but its quite a bit more flexible, and after all, timtowtdi :)
relaxed time using WebObjects. Enough said ...
If web hosts made inline Python, Ruby and Perl modules like mod_python availible to their users, few people would choose PHP over those three.
I disagree: I think all three of those languages and runtimes have significant disadvantages compared to PHP for web applications. In fact, mod_python and mod_perl are old enough that if they were the best choice, they'd be more widely used.