Comments on the upcoming PHP 5.5/6.0..

[Edman]

I'd like to say that regardless of what features PHP 6 might have, it's release is completely irrevelent to my daily workflow

I second this, PHP6 might have the best features ever, but it's not gonna matter even a slight bit because I can't even work with PHP5 yet! Not a single server I have to work with is running PHP5!

[turboweb]

Having run dozens of servers i won't be "upgrading" to php5 anytime soon. Perhaps on new servers we may roll out updates and force people to upgrade.

Problem is many of the scripts people have spent years building/customizing still don't work good or at all under php5.

Not really an issue with webhosts but an issue with everything being designed around incompatible code that is just now being fixed.

Many of the popular cms systems come to mind..

[PSPF]

The changes do look pretty good, but they need to take more time on the updates..

[Etnu]

I'm still not seeing where these upgrade issues are coming from. I'd be willing to wager that the problem is coming from a systems administrator who doesn't know how to compile --with-mysql more than anything else. I'm in charge of the PHP installations on dozens of servers running tons of php4 applications (all the big ones that you're used to; PostNuke, phpBB, vBulletin, etc.), and they all work just fine. In fact, with the exception of a few extra warnings and noticed (typically the "wtf are you doing!?!!" variety, like call time pass by reference), I've yet to see any major app that breaks when running on a php5 setup.

The benefits for using php5 far, far outweigh those little warnings and notices.

[chinaguy]

I do not understand why it matters if hosts have upgraded or not. If PHP4 works great for them, then let them keep it for the next 20 years. As for those people that are leading the curve, they can upgrade to the latest version and enjoy new features. Personally, I hope that 6 months after they release 5.5/6 they will release PHP 7 (fully bugged, of course) with a whole slew of new features.

[mwolfe]

Its pretty clear why it matters to many people here, because they code for a living. If the technology is out, but nobody is supporting it, then it doesnt do them any good to try and use its advantages when it won't work on the server.

[spyross]

PHP5 was released over a year ago with half way deceit backwards compatibility however not one of my host have upgraded yet. Along comes PHP6 backwards compatibility questionable to shaky with PHP4 and PHP5 ... just how far behind do they think they can leave the hosting community?

OpCode Cache!!! I've been waiting for that. Wonder how Zend feels about that addition?

PHP is not just about creating nice and simple database driven websites.
PHP is - even as is - powerful enough to be used for developing powerful web based applications. Web hosts that just focus on hositng simple websites can still use PHP4 for as long as they like. I don't see why I sould have register_globals off for a website that just retrieves some trivial content data from a database has a contact form.

On the other side, companies that rely on applications that need the extra power and features can and should use next versions of PHP.

Nevertheless removing register_globals is a good step into making good programming practice a standard, something many php programmers lack (probably myself included).

[auctionmonsternt]

I can sum up the reason for the early release with two words (book sales)

[Etnu]

PHP is not just about creating nice and simple database driven websites.
PHP is - even as is - powerful enough to be used for developing powerful web based applications. Web hosts that just focus on hositng simple websites can still use PHP4 for as long as they like. I don't see why I sould have register_globals off for a website that just retrieves some trivial content data from a database has a contact form.

On the other side, companies that rely on applications that need the extra power and features can and should use next versions of PHP.

Nevertheless removing register_globals is a good step into making good programming practice a standard, something many php programmers lack (probably myself included).

<?php
require('db.php');
$handle = mysql_connect($db_host,$db_user,$db_pass);
mysql_select_db($db_database,$handle);
switch($do)
{
   case 'update':
       mysql_query('UPDATE '.$table.' SET '.$field.' = '.$val.' WHERE id='.$id); 
   break;

   default:
      exec($cmd);
   break;
}

?>

Obviously this is kind of the extreme case, but if I were a host, I would simply never let register_globals be on any server that I run.

[/php

[DougBTX]

<?php
require('db.php');
$handle = mysql_connect($db_host,$db_user,$db_pass);
mysql_select_db($db_database,$handle);
switch($_GET['do'])
{
   case 'update':
       mysql_query('UPDATE '.$_GET['table'].' SET '.$_GET['field'].' = '.$_GET['val'].' WHERE id='.$_GET['id']); 
   break;

   default:
      exec($_GET['cmd']);
   break;
}

?>

I suppose that's where magic quotes comes in...

[Carl]

I think many are confusing the backwards compatibility issue with proper project control. php5 and php6 would be the same branch. php6 would exist because of the version number conventions used nowadays to seperate major changes in software operation by going to a full version number rather than a point. The changes listed are very major. So php5 would only exist up to 5.04 and then become php6. Web hosts will consider this reasonable and hang along for the ride.

As far as the complaints of just now getting to php5 and now having to do php6. They don't hold water. Unlike Microsofts changes in .NET technology the changes stated are not items that need to be learned or will effect present use. If you are learning or using php5 then most of the items are things that you should not be using or will not have to learn about. So backwards compatibility becomes a non factor.

[JosephRagsdale]

What is the general opinion about Unicode support among the PHP developers? What does Unicode support mean?

What will strings be stored as internally? I suspect UCS-4. There's several Unicode encodings: UCS-2 and UCS-4 along with the transformation formats UTF-8 and UTF-16. There's also little endian and big endian, and the byte-order-mark to be concerned with.

Will there be special print, echo, and company functions for each encoding? Will print, echo, and company have parameters for the encoding to be used? Perhaps the encoding can be set with a seperate function, much like for how the locale is set.

I suspect the developers will use IBM's ICU. I've been using it with my own applications in C. It's quite nice and easy to learn.

[DougBTX]

Joseph, read the PHP internals mailing list archives to get a picture of what the plans are. Internally, I believe most things will be in UTF-16, with no special print, echo, etc functions. The last I saw, there was still some disagreement on whether support for turning unicode support off would be possible, the results of that will probably affect the final setup.

Douglas