Saturday, November 10. 2007
 |
 |
 |
 |
Posted by Frank Kleine
in
Planet PHP Comments (2) Trackbacks (0) |
 |
 |
 |
 |
Subtle BC break in PHP 5.2.4
Today while evaluating PHP 5.3 I stumbled about a subtle BC break which has already been introduced in PHP 5.2.4. Consider the following code:
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:
And the result with PHP >= 5.2.4:
Spotted the difference? In the second array the private member is not there any more. While this may be correct from the object-oriented point of view I wonder whether this really must have been fixed in a bugfix release - ok, it is obviously a bug, but I would consider the change a BC break as well. On the other hand no one really complained until now.
However the new behaviour is a bit sad because this means you can not implement a method in your base class that returns a list of all members of any arbitrary child class regardless of their visibility including their value. (Well you can, but casting the object to an array and fixing the keys is a bit messy.) Good bye, my simple __toString() method in the base class...
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"
}
Spotted the difference? In the second array the private member is not there any more. While this may be correct from the object-oriented point of view I wonder whether this really must have been fixed in a bugfix release - ok, it is obviously a bug, but I would consider the change a BC break as well. On the other hand no one really complained until now.
However the new behaviour is a bit sad because this means you can not implement a method in your base class that returns a list of all members of any arbitrary child class regardless of their visibility including their value. (Well you can, but casting the object to an array and fixing the keys is a bit messy.) Good bye, my simple __toString() method in the base class...
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
be sure to sure to submit an addition to the upgrading guide whenever you find something like this.
I submitted a note now to the manual page for migration from 5.1 to 5.2 in the section of backward incompatible changes.
Calendar
|
September '10 | |||||
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | |||
Archives
Categories
Quicksearch
Blogs we read...
Syndicate This Blog
Blog Administration
