Although most existing PHP 5 code should work without changes, you should pay attention to the following backward incompatible changes:
NULL when passed
incompatible arguments as of PHP 5.2.1.
TRUE on success as of PHP 5.2.1.
TRUE on success as of PHP 5.2.1.
FALSE.
As of PHP 5.2.0, this operation will emit an E_WARNING,
as is the case in all other instances where division by zero is performed.
<?php
print 10 % 0;
/* Warning: Division by zero in filename on line n */
?>
<?php
class foo {}
$foo = new foo;
print $foo;
/* Catchable fatal error: Object of class foo could
not be converted to string in filename on line n */
?>
<?php
class foo {
public function __toString() {
throw new Exception;
}
}
try {
print new foo;
/* Fatal error: Method foo::__toString() must
not throw an exception in filename on line n */
} catch(Exception $e) {}
?>
<?php
abstract class foo {
abstract static function bar();
/* Strict Standards: Static function foo::bar()
should not be abstract in filename on line n */
}
?>
<?php
/* when allow_url_include is OFF (default) */
include "data:;base64,PD9waHAgcGhwaW5mbygpOz8+";
/* Warning: include(): URL file-access is disabled
in the server configuration in filename on line n */
?>
FALSE when
openbase_dir restrictions are violated.
str_pad has been modified as well, to enforce UPPERCASE sensitivity on the pad_type declaration.
Optional argument pad_type can be STR_PAD_RIGHT, STR_PAD_LEFT, or STR_PAD_BOTH. If pad_type is not specified it is assumed to be STR_PAD_RIGHT.
If entered as:
$foo = 10;
$wrong = str_pad($foo, 4,'0',str_pad_left);
print "wrong is '$wrong'<br>";
$right = str_pad($foo,4,'0',STR_PAD_LEFT);
print "right is '$right'<br>";
results:
wrong is ' '
right is ' 10'
If the sole reason for having "abstract static methods" is to force the implementation of such a method in a child, consider using an interface for them. The abstract class implements the interface, and a child class extends the base class and defines the "abstract static methods".
<?php
interface I
{
static public function f();
}
abstract class C implements I
{
// more/other methods go here
}
class D extends C
{
static public function f()
{
echo 'I am f().';
}
}
?>
If any of your code relies on includes of URLS à la allow_url_fopen, be aware that a new directive (allow_url_include) has been added, and that it defaults to Off.
Between PHP 5.2.3 and 5.2.4 another backward incompatible change was introduced: parent classes now can not access private properties of child classes with get_object_vars(). See the following example:
class Bar {
public function dumpBar() {
var_dump(get_object_vars($this));
}
}
class Foo extends Bar {
public $public = 'public';
protected $protected = 'protected';
private $private = 'private';
public function dump() {
var_dump(get_object_vars($this));
}
}
$foo = new Foo();
$foo->dump();
$foo->dumpBar();
The result with PHP < 5.2.4:
E:\php\tests>php get_object_vars.php
array(3) {
["public"] => string(6) "public"
["protected"] => string(9) "protected"
["private"] => string(7) "private"
}
array(3) {
["public"] => string(6) "public"
["protected"] => string(9) "protected"
["private"] => string(7) "private"
}
And the result with PHP >= 5.2.4:
E:\php-5.2.4-Win32>php ../php/tests/get_object_vars.php
array(3) {
["public"] => string(6) "public"
["protected"] => string(9) "protected"
["private"] => string(7) "private"
}
array(2) {
["public"] => string(6) "public"
["protected"] => string(9) "protected"
}
As you can see the private property is missing now when dumped from the parent class Bar.
It should be noted that if you provide a __toString method, you can cast the object to a string and use it as an array key (PHP 5.2.x).
e.g. $array[ (string)$myObject ] = 'foobar';
This is an alternative to using spl_object_hash.