|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #49216 Reflection doesn't seem to work properly on MySqli
Submitted: 2009-08-11 07:18 UTC Modified: 2010-07-08 12:20 UTC
Avg. Score:5.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: virgilp at gmail dot com Assigned: mysql (profile)
Status: Closed Package: MySQLi related
PHP Version: 5.2.10 OS: Windows XP SP3
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: virgilp at gmail dot com
New email:
PHP Version: OS:


 [2009-08-11 07:18 UTC] virgilp at gmail dot com
There are several things that go wrong with reflection on MySqli. 
1. First and foremost - extracting mysqli::bind_param signature yields 
strange results:  public function bind_param($);
And the parameter in question (printed as "$") is in fact:
   'name' => NULL,
))  /// Null name!!
I believe this is actually related to bug #45578 - but that one has 
been closed as being related to something completely different.

2. another odd thing is that reflection returns "final protected class 
mysqli_warning " (and a class can't be "protected").

3. Several properties seem to be completely missing from reflection - 
e.g. the "host_info" property of mysqli.

4. Parameters are not shown in member methods - e.g. mysqli::prepare 
is shown to have 0 parameters (when in fact, it receives a string 

Reproduce code:
$ext = new ReflectionExtension('mysqli');
$class_arr = $ext->getClassNames();
foreach($class_arr as $cls_name){
 // I could give the implementation of DumpClass if needed, but it's straight out of the "reflection" examples, it prints the modifiers, class name, "extends", "implements" & properties/methods

Expected result:
MySqli class seen through reflection the same way as it is documented on

Actual result:
Wrong output from reflection (as listed in "description")


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-08-12 07:04 UTC] virgilp at gmail dot com
I tried - I get the same behaviour
 [2009-09-02 19:25 UTC]
host_info and such is only there when you actually have connected 
somewhere. How about you refine your report and try with an actual 
object first?
 [2009-09-09 17:10 UTC] virgilp at gmail dot com
1. You forgot about the "protected class" mysqli_warning.

2. Then run the following program, and explain its results. I added 
mysqli_stmt only for reference, so that you see the similarity:

function PrintParams($classname, $methodname){
   $class = new ReflectionClass($classname);
   $method= $class->getMethod($methodname);
    echo "$classname::$methodname():\n";
   $parameters = $method->getParameters();
  foreach ($parameter as $param)
    echo "$param : ".$param->getName()." \n";




3. furthermore - new reflection issues, not really related to MySqli: 
a bunch of interfaces have no extension associated. For example try 
php.exe --rc RecursiveIterator -you'll see that it prints 
<internal:SPL> (which is probably correct). But php.exe --rc Iterator, 
or php.exe --rc ArrayAccess will print only <internal>. 
Coincidentally, this means that you can't find the "Iterator" 
interface in any extension (e.g. using 
ReflectionExtesions::GetClasses) - IMO, it should be either in "SPL" 
or in "standard", but not completely "missing".
 [2009-09-09 17:20 UTC] virgilp at gmail dot com
Just to clarify - the previous program shows the following results on 
my machine:
Parameter #0 [ <required> $param0 ] :
Parameter #0 [ <required> $param0 ] :
Parameter #1 [ <required> $param1 ] :
Parameter #0 [ <required> $function_name ] : function_name
Parameter #1 [ <required> $arguments ] : arguments
Parameter #2 [ <optional> $options ] : options
Parameter #3 [ <optional> $input_headers ] : input_headers
Parameter #4 [ <optional> &$output_headers ] : output_headers

Notice that bind_param, as well as SoapClient::__call do not return 
any "name" for the parameters (although printing the parameter 
directly will show a name). In contrast with that - _soapCall will 
correctly show the names
 [2009-09-09 17:26 UTC] virgilp at gmail dot com
Oh, and about your supposition that I need an actual object... that's 
not true, either. Try this:
$mysqli = mysqli_init();
if (!$mysqli) {
    die('mysqli_init failed');

if (!$mysqli->options(MYSQLI_INIT_COMMAND, 'SET AUTOCOMMIT = 0')) {
    die('Setting MYSQLI_INIT_COMMAND failed');


With the PrintParams function being the one from my previous example. 
I get the following output:
$ php.exe d.php

Surprise-surprise, it does get to PrintParams (meaning that it doesn't 
die, and I did successfully create a MySqli object). But what do you 
know, the "options" function still shows as being one with no 
parameters. So maybe they were optional parameters? Nope, this is what  
I get if I give no parameters:

Warning: mysqli::options() expects exactly 2 parameters, 0 given

As it turns out, it doesn't matter if you created one MySqli object... 
the reflection is still buggy.
 [2009-09-10 12:33 UTC] virgilp at gmail dot com
I found something interesting.
As it turns out, you may need to "refine" the site... the code 
written there seems to be no good, according to your latest feedback - 
because it works just like my example:

And there are others, too, for instance this one:
(probably not a reflection bug either, just an unrefined "class.php" 
 [2010-04-15 12:52 UTC]
-Assigned To: +Assigned To: mysql
 [2010-07-06 19:30 UTC]
working on this, needs arginfo here and there. Will be, however only 5.3+
 [2010-07-08 12:20 UTC]
-Status: Assigned +Status: Closed
 [2010-07-08 12:20 UTC]
Fix will appear in 5.3.3

PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue May 21 23:01:31 2024 UTC