Edit report at http://bugs.php.net/bug.php?id=50636&edit=1
ID: 50636 Updated by: abedf...@php.net Reported by: stein at rhrk dot uni-kl dot de Summary: MySQLi_Result sets values before calling constructor -Status: To be documented +Status: Closed Type: Bug Package: MySQLi related Operating System: * PHP Version: 5.2.12 Assigned To: abedford Block user comment: N New Comment: Note added to documentation. Previous Comments: ------------------------------------------------------------------------ [2010-10-05 18:26:19] abedf...@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-05-28 15:03:42] 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-02-12 06:18:38] stein at rhrk dot uni-kl dot de @ johan...@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-02-11 22:50:26] johan...@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-11 21:42:48] s...@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) ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=50636 -- Edit this bug report at http://bugs.php.net/bug.php?id=50636&edit=1
