Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×

PHP 6 and What to Expect 101

Posted by ScuttleMonkey from the no-stopping-this-freight-train dept.
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."
This discussion has been archived. No new comments can be posted.

PHP 6 and What to Expect More

PHP 6 and What to Expect

Comments Filter:

  • Article (Score:3, Informative)

    by perlionex ( 703104 ) * <[joseph] [at] [ganfamily.com]> on Tuesday March 14, 2006 @04:19AM (#14914160)

    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 [slashdot.org], 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 [php.net], magic_quotes [php.net] and safe_mode [php.net] 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 [php.net]: 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 [cplusplus.com] 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

    • Re:Article (Score:1, Flamebait)

      by D'Sphitz ( 699604 )
      Since jero.net already seems to be /.ed...

      No it's not, quit karma whoring

    • 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 wa

  • Comment removed (Score:5, Interesting)

    by account_deleted ( 4530225 ) on Tuesday March 14, 2006 @04:20AM (#14914165)
    Comment removed based on user account deletion
    • It really depends on what you use PHP for, how you like to code, how many people are working on the project, whether you prefer OO or procedural code, whether you mix PHP and HTML or not, and so on.

      I, personally, will probably move to it fairly quickly because I can do it -- noone's going to be too bothered if my personal sites blow up, because I make use of the new features introduced in PHP 5 today, and because I wish for the consistency that PHP lacks right now.
    • I reckon Perl's OO support could use a bit of work, but I'm not very experienced with it, so maybe it just takes some getting used to.

    • Re:Do most users even need PHP 6? (Score:4, Insightful)

      by masklinn ( 823351 ) <.slashdot.org. .at. .masklinn.net.> on Tuesday March 14, 2006 @08:18AM (#14914772)

      Try some other languages (Ruby, Python, CLisp/Scheme/Haskell/OCaml if you manage to get past the syntax), you'll see that PHP is lacking in many areas.

      Closures (even read-only, as in Python), functions as first-class objects, namespaces, modules, consistency across the standard library, properties, metaobjects, strong typing (not static, strong), infinite-length integers (these dummies want to add a 64bits integer in PHP6... whoa, so kewl eh), good iterators (not Java's, either Ruby style or Python style iteration), partial application (curryfication), pattern matching, ...

      • Re:Do most users even need PHP 6? (Score:4, Insightful)

        by self assembled struc ( 62483 ) on Tuesday March 14, 2006 @12:12PM (#14916328) Homepage
        I think you're missing his point.

        In my experience (working in large PHP driven shops) the people writing PHP didn't necessarily have a comp sci background. They don't care (and most don't even know) wahat a first-class object is, why they would even want namespaces, strong typing or 64 integers. In fact, adding them to the language makes it in accessible to them, so they'll just stick with php 4, which "works for me."

        I mean, in a fundamental sort of way, yes PHP is broken, but in a useable sort of scripting language way, PHP 4 isn't broken. And if it ain't broke, then don't try to fix it.

  • Namespace (Score:4, Insightful)

    by CHaN_316 ( 696929 ) on Tuesday March 14, 2006 @04:28AM (#14914192)
    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.

    • Re:Namespace (Score:5, Informative)

      by iangoldby ( 552781 ) on Tuesday March 14, 2006 @04:50AM (#14914245) Homepage
      From the article:

      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.


      Will this do?
      • It'll do, however OOP isn't the only programming paradigm that people use with PHP. I know quite a few people that use PHP for its functional programming abilities. (Just making conversation, not knocking OOP)
    • it can (sorta) be done in php4/5 via a static class function. Still, it will be a nice addition.
    • it'd be great if they'd get php5 up and running properly before they put their effort into php6 ;)

      i still get segfaults with xslt processing on every typo that's in the xslt file, so i have no line numbers or even filenames to track down the error that causes it to segfault :S

      other than that, adding a more proper oop support in php5 is a very welcome addition.

      namespaces ? sure they'd be good to use in complex applications, but proper oop code can easilly live without them.

      some fast way for persistant data i

  • woohoo! (Score:2, Funny)

    by larry bagina ( 561269 )
    I'm glad that register globals and magic quotes will finally (hopefully) be dead. I can't believe they implemented those "features" in the first place, much less made them default. ughh!

    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!

  • Lack of backwards compatibility (Score:5, Interesting)

    by kestasjk ( 933987 ) on Tuesday March 14, 2006 @05:02AM (#14914278) Homepage
    phpBB, vBulletin, mysqladmin, postnuke, phpDiplomacy [kuliukas.com] (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 [phpbb.com]; I'm starting to wonder if I should have focused on a more stable language like python or perl instead.
    • >phpBB[...]; 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.

      I'll note that phpBB 2.0.x was written for PHP3 and PHP4 (those were the only target versions of PHP about when 2.0.0 was released). The fact that 2.0.x works with PHP5 is proof that there's enough backwards compatability with PHP4. The bits that break are proof that there's not enough ;)

      Also, phpBB 3.0 is being wirtten for PHP4 and PHP5, of which it works fine under both r

    • One of the nasty aspects of web design is the speed of it. The next great standard, the next new browser, all these things impact your code negatively. Talk about an uphill battle!

      After many trial and error experiences, I've started to force myself to segregate different types of information as much as possible. Separate content from markup, markup from script, etc. Times change, and the code you're using will change with them. If you keep different portions of a page separated, it makes it easier to updat

    • Comment removed based on user account deletion
  • The argument why .PHP is seen as being less of a programming language to .NET is its lack of framework support.

    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 .PHP being not quite enough agaisnt competeing solutions.

    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 sayi
    • Otherwise I presonally believe we'll start seeing Ruby hit the scene a bit more and .PHP will be left to catch up.

      This already happened
    • The argument why .PHP is seen as being less of a programming language to .NET is its lack of framework support.

      Actually .NET is not a programming language, it's a platform. Many languages run on the .NET platform, PHP [php-compiler.net] amongst others.

    • 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
  • This would be really great!!!
  • Namespacing and first-class Unicode strings are two things PHP is still seriously lacking. Now that they are promised in PHP6, it will finally be... er... an average modern language roughly on par with Python feature-wise?

    Seriously though, apart from its popularity, is there any reason to choose PHP over the multitude of other existing solutions?

    • I worked on some rather ambitiously complicated content management projects for a couple of years in PHP4 and i have to say it was a bit of a toy language.

      I started designing an App framework for PHP5 (since it has rudimentary OO support) to eliminate wheel reinvention for even trivial requirements like data/type validation. But then Ruby on Rails came out and it looked like exactly what i was trying to do except on a better foundation and with someone else doing all the work ;)

      PHP4/5 seemed scrappy, bu

    • Seriously though, apart from its popularity, is there any reason to choose PHP over the multitude of other existing solutions?

      If you actually know how to code, not really, no.

      On the plus side, it's extremely easy to get started (just create a .php file and start emitting a mess of PHP and HTML) which is good for 2-pages stuff or for beginners (not good as in "teaches you how to code", but good as in "well at least it does something, and you don't even have to being understanding how it does it), on the

    • the manual is amazing

  • GOTO? (Score:2, Insightful)

    by Two9A ( 866100 )
    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?

    • Admittedly, I didn't RTFA, but 'goto' is almost definite to be included in PHP6 upon release.

      Perhaps you should try RTFA (yeah, yeah, this is slashdot, blah blah...) From http://www.php.net/~derick/meeting-notes.html#addi ng-goto [php.net]

      The name "goto" is misleading, and often associated with BAD THINGS(tm). Because our proposed solution is not a real GOTO construct, we will instead reuse the "break" keyword, and extend it with a static label.

    • Real Programmers aren't afraid to use GOTO's.

    • 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?

      The whole noise against goto is utterly pointless. If your functions are large enough that goto makes them unreadable, you should break them up anyway. And if you insist on keeping them intact, then using goto islikely to result in a lot cleaner code than monstrous multi-layered block str

    • pandering to the VB migration crowd

      Interestingly enough, I've seen more GOTOs in 'hardcore' C code (just look at the Linux kernel) than I ever saw on VB. So what's your excuse for hating VB?

  • PHP needs serious redesigns (Score:5, Insightful)

    by tehshen ( 794722 ) <tehshen@gmail.com> on Tuesday March 14, 2006 @08:03AM (#14914741)
    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.
    • I completely agree about just creating a new language. Keeping things backwards compatiable just messes up future releases.

      The lesson learned here is that computers should not try to act smart (magic quotes and register globals). I am smart enough to add_slashes() my input.
    • 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.

      You mean we could do something like this?

      $dbh = new PDO('mysql:host=localhost;dbname=test', $user, $pass);
      foreach ($dbh->query('SELECT * from FOO') as $row) {
      print_r($row);
      }
      $dbh = null;

      Wouldn't that be neat? This is a

    • [PHP's design is fucked up. Some functions have underscores, others don't; some have numbers, others don't]

      This is the sum of your critique of the language!?! You don't like the name of some of the functions that are included with it?!?

      For $5 I'll sell you a patched PHP, just give me your list of preferred functions, and you can have (apparently) the perfectly designed language.

      I say Perl's design is fucked up. The different sigils are on different parts of the keyboard. @ isn't next to % and by god, $ c

  • Comment removed (Score:3, Interesting)

    by account_deleted ( 4530225 ) on Tuesday March 14, 2006 @09:12AM (#14914952)
    Comment removed based on user account deletion
  • It's a pity they decided in favor of APC and not eAccelerator [eaccelerator.net] (the successor of turck mmcache), which is a lot faster in my experience.
    • they state in the notes that they chose it because APC is released under the PHP license so they can include it with the release. I know Bart is going to be working on redoing all the eaccelerator code so he can change it to the PHP license as well but that will take considerable time. I also wonder whether it would still be enough. Ive seen benchmarks that put eAccelerator in front of Zends own product, which Zend must not be too happy about. But its good to see at least some caching be put out there even
  • 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
  • to make PHP strong typed!!

  • PHP's biggest problem (Score:4, Informative)

    by rnd() ( 118781 ) on Tuesday March 14, 2006 @01:36PM (#14917233) Homepage
    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.
    • Actually, they mentioned this in the article. It was decided that they would not use exceptions for built in functions, because they couldn't decide where to draw the line between throwing an exception and halting the interpreter.
      I agree that it would be a nice option to have, though in my experience the only language I've worked with on any regular basis where people actually use try/catch blocks instead of the return false way is in Java, which requires it.
      • Seems strange to just halt the interpreter under any circumstances. Why not give the programmer the choice about what happens?

        C# support exceptions very similar to Java's and they're not required, but they are available to create robust code when it is needed, unlike PHP.

        Ruby also has a similar mechanism with slightly different syntax; optional but highly useful.
  • 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).
  • Comment removed based on user account deletion

Slashdot Top Deals

I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"

Close