php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #50636 MySQLi_Result sets values before calling constructor
Submitted: 2010-01-02 15:03 UTC Modified: 2010-10-05 18:27 UTC
Votes:2
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:1 (50.0%)
From: stein at rhrk dot uni-kl dot de Assigned: abedford (profile)
Status: Closed Package: MySQLi related
PHP Version: 5.2.12 OS: *
Private report: No CVE-ID: None
 [2010-01-02 15:03 UTC] stein at rhrk dot uni-kl dot de
Description:
------------
MySQLi_Result::fetch_object sets properties before calling the constructor, see BUG #49521

The behavior is similar to the one in BUG #49521 which has been fixed as of PHP 5.2.12.

Note: It should be considered that this behavior may be not bug at all. Calling the constructor BEFORE setting the properties (as done in BUG #49521) leaves no possibility to work with the data at "construction time" of the object.

Setting default properties could be done by assigning them in the class-definition, but setting other properties depending on the loaded data is hard to do, when this data is not yet available when the constructor is called. This problem is even harder to solve, as no setters for the properties are called, even if they are declared as private.

Reproduce code:
---------------
class Test
{

  private
    $myprivate       = 0;

  function __construct()
  {
    echo 'constructor called, $myprivate is ', $this->myprivate;
  }

  function __set ( $name, $value )
  {
    echo 'setting ', $name, ' to ', $value;
    $this->{$name}   = (int) $value;
  }

}

$mysqli->query('SELECT 1 AS myprivate, 2 AS mypublic')->fetch_object('Test');


Expected result:
----------------
If the same way to handle this bug as in BUG #49521 is considered:

constructor called, $myprivate is 0
setting mypublic to 2

object(Test)#6 (2) {
  ["myprivate:private"]=>
  string(1) "1"
  ["mypublic"]=>
  int(2)
}

But maybe the following behavior would make more sense if it should be changed:

constructor called, $myprivate is 0
setting myprivate to 1
setting mypublic to 2

object(Test)#6 (2) {
  ["myprivate:private"]=>
  int(1)
  ["mypublic"]=>
  int(2)
}




Actual result:
--------------
setting mypublic to 2
constructor called, $myprivate is 1

object(Test)#6 (2) {
  ["myprivate:private"]=>
  string(1) "1"
  ["mypublic"]=>
  int(2)
}


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-01-03 16:59 UTC] svn@php.net
Automatic comment from SVN on behalf of pierrick
Revision: http://svn.php.net/viewvc/?view=revision&revision=293039
Log: Fixed bug #50636 (MySQLi_Result sets values before calling constructor)
 [2010-01-03 17:00 UTC] pierrick@php.net
This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.


 [2010-02-11 21:42 UTC] svn@php.net
Automatic comment from SVN on behalf of johannes
Revision: http://svn.php.net/viewvc/?view=revision&revision=294901
Log: revert 293939 Fixed bug #50636 (MySQLi_Result sets values before calling
constructor)
 [2010-02-11 22:50 UTC] johannes@php.net
As you said in your note: This feature might be unclean from an OO perspective but is a "feature". Maybe this can be made clearer in the docs.
 [2010-02-12 06:18 UTC] stein at rhrk dot uni-kl dot de
@ johannes@php.net

Thanks for your comment, but i have a further question: Why was this approach chosen, when it is considered as "unclean"? No offend, but i?d like to understand the reasons that lead to the decision to consider the setting of properties after calling the constructor is the correct behavior, not vice versa.

To make my intention clearer: I widely used the old behavior in a very large codebase to automatically assign rights for objects from a database depending on it?s properties and the user?s groups. It was a very neat feature, as i could make all constructors and properties private, so no objects could be generated by users accidentally. I know that i relied on an undocumented feature, but this behavior seemed logically correct to me. After the change, all applications depending on this codebase were broken. In the meantime i changed the complete code to work with the new behavior, but the result is not as reliable and much more "bloated" as the former one due to the impossibility of working on the object?s loaded data.

When you set the properties after calling the constructor, what sense does the constructor make in the end when there is no data to work on for it? Setting default properties can be easily done in the class definition. But working reasonable with the object?s constructor is only possible, when there already is data to work on.

Even if the current approach is favored it would be at least very helpful to call _set for private and protected properties, as the current behavior of setting this properties directly breaks with the rules of visibility and therefor - in my eyes - makes no sense at all.

Thanks in advance.
 [2010-05-28 15:03 UTC] alex at bsingular dot eu
I do not think this is behavior is wrong. 
If the vars where protected the __set and __get functions where called even if 
no constructor is called.

I think you can implement read only properties with this behavior

Check this example. You will see that when fetch_object is called all properties 
are setted.
After the fetch_object call that property will be read only.

class Test {
 protected $_init=false;
 protected $_field1=null;
 protected $_meta=array('_field1'=>1);
 
 	public function __construct(){
		$this->_init=true;
	}
	
	public function __set ($name, $value)
	{
		if($this->_init && $this->_meta[$name]){
			throw new Exception('read only');
		}
		
		$this->$name=$value;
	}
	
}
 [2010-10-05 18:26 UTC] abedford@php.net
Automatic comment from SVN on behalf of abedford
Revision: http://svn.php.net/viewvc/?view=revision&revision=304111
Log: Note added as per bug #50636
 [2010-10-05 18:27 UTC] abedford@php.net
-Status: To be documented +Status: Closed
 [2010-10-05 18:27 UTC] abedford@php.net
Note added to documentation.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 11:01:28 2024 UTC