Question

I’ve just started to extend the MySQLi class and found that member variables created in the child class don’t display as part of the object when using print_r or var_dump etc.

Take for example this sample

class Database extends MySQLi {
    public function __construct( $h, $u, $p, $n ) {
        parent::__construct( $h, $u, $p, $n );

        $this->name = $n;
    }
}

When running the following, the member variables one would expect to see in an MySQLi object are present and output successfully. However, the member variables I create are not present.

$obj = new Database( 'a', 'b', 'c', 'd' )
print_r( $obj );

I found however that I can use calls to echo $obj->name successfully.

On further inspection I am able to successfully inspect the object using the following:

print_r( get_object_vars( $obj ) );

Array
(
    [name] => my_database
    [affected_rows] => 
    [client_info] => 
    [client_version] =>

[...]

I found this question but it doesn’t really offer an answer- the accepted solution suggests that it’s impossible, one answer comes to the same conclusion as me, and the other is irrelevant.

The manual for print_r() suggests that in theory my member variables should be shown because they’re not static.

print_r(), var_dump() and var_export() will also show protected and
private properties of objects with PHP 5. Static class members will
not be shown.

Is there a way in which I can extend the MySQLi class and be able to quickly debug my database objects using print_r without the requirement for get_object_vars(). Is this intended behavior or a bug which should be reported to the developers of PHP?

I am using PHP Version 5.3.5 on Windows 7. I’ve yet to test this on my Linux development environment.

Answer 1

Yes – by overwriting the __toString()-Magic Method, you can dump it however you want by writing your own dumping function. As you have your own environment, you might also check out debugging php with xdebug and get a lot more power.