From what I read, PHP 6 will break a lot of php scripts. I understand the reasons why it may break but why don't they just keep the PHP 5 and simply call PHP 6 as a different language based on PHP syntax? Like for example, why not just call php 6 scripts with an extension, "p6"- why are they trying so hard to make it backward compatible for old scripts when the extension can be used to call a specific interpreter?
A:
Well, PHP doesn't care about the file extension. You could probably set up a web server to map a particular extension to a different PHP interpreter. But then what if you had a PHP6 script that included a script meant for PHP5?
I think it's easier to just stick to one interpreter per server, and move your projects to a PHP6 server once you've upgraded and tested the code.
JW
2010-01-23 05:21:39
A:
That's not for PHP to decide, Apache for instance allows to specify which version of the PHP engine to call based only on the file extension, that's they reason you sometimes see files like .php3 or .php4.
When PHP 6 comes out you'll probably see some .php5 files in the wild and .php will be the default.
But don't worry, PHP 6 isn't the nightmare you're imagining, on the contrary.
Alix Axel
2010-01-23 05:21:55
+1
A:
You can call php6 scripts with a specific version of php, and you can use the extension p6 if you want. It is all a matter of how your webserver is set up.
As long as your have both php5 and php6 installed, you could have .php files run by php5 and .p6 files run by php6.
sberry2A
2010-01-23 05:22:33
+2
A:
To put it simply, there is always a better way of doing things. This is true for all languages, new versions of GCC and Visual Studio break older C/C++. Another example is Python 3.x broke a whole lot of python 2.x code. All of this was done on purpose. The reason why is that programmers make mistakes and the next release gives and opportunity to make the platform better for everyone.
There are some serious mistakes that exist in PHP5 and Zend is trying to correct these problems in PHP6. The serious mistake that sticks out most in my mind is magic_quotes_gpc and register_globals. These should have never been included in the language as they lead to vulnerabilities because ether the programmer is lazy or because PHP is misconfigured. Both of magic_quotes_gpc and register_glboals are being removed in PHP6, and as a friendly white hat hacker I am happy to see them go. However, if your application depends on ether one of these features then its possible to make your code compatible and also weaker to exploitation.
Rook
2010-01-23 05:36:24
A:
You can make your PHP5 compatible with PHP6. I have made below file for my projects so that they are future-compatible. All content has been put in place after reading from PHP6 developer conference.
File: is_php6.php
<?php
// This file does the proper handling of functions/etc for compatibility if we are
// under PHP6
/*
------------------------------------------------------
PHP6 NOTES
------------------------------------------------------
1. Call Time Pass by Reference
-------------------------------
Don't initiate your objects with the reference operator anymore.
// incorrect
$var =& new stdObject(); //current object reference
// correct
$var = new stdObject(); //just do this instead
2. register_long_arrays, HTTP_*_VARS
-------------------------------------
Removed and if you are not using $_POST and $_GET, do so!
3. Case Sensitivity
-------------------
Case insensitivity of functions and classes. Use case-sensitive names
4. ereg
-------
ereg removed. use preg instead.
5. Strings and {}
-----------------
Instead of using $somevar{1}, use $somevar[1]
6. Error Supression @
----------------------
Because @ operator is very slow, it won't work on ini_set eg @ini_set.
7. break $somevar
-----------------
Removed support for dynamic breaks. You can't do this:
break $somevar;
You need to find an alternative to that.
8. Database Extensions/Objects
------------------------------
Use PDO as early as you can (PHP 5.1). Their plan is to slowly move
Non-PDO database extensions out of the core. It is good idea to migrate
to those as soon as you can.
9. ASP Style Tags <% %> and Short Tags
--------------------------------------
ASP style tags are no more supported. Also for security reasons, you should
use full PHP tags eg <?php ?> instead of <?=$somevar?>.
10. safe_mode
-------------
No more there.
11. var
------------
"var" keyword is now an alias of "public"; not used for variable declaration any more.
12. Support for Freetype 1 and GD 1
--------------------------------------
Support for both of them removed cause they are archaic.
13. ?: operator
----------------
They drop the middle value for the ?: operator eg:
*/
if (version_compare(phpversion(), '6', '>='))
{
// no more register_globals
if (ini_get('register_globals'))
{
ini_set('register_globals', false);
}
// no more magic quotes
function get_magic_quotes_gpc()
{
return false;
}
// zend compatibility mode setting
if (ini_get('zend.ze1_compatibility_mode'))
{
ini_set('zend.ze1_compatibility_mode', false);
}
// disable magic_quotes_runtime
if (get_magic_quotes_runtime())
{
@set_magic_quotes_runtime(0);
}
}
?>
Sarfraz
2010-01-23 05:37:12