Bug #50636 [Com]: MySQLi_Result sets values before calling constructor
Edit report at http://bugs.php.net/bug.php?id=50636edit=1
ID: 50636
Comment by: alex at bsingular dot eu
Reported by: stein at rhrk dot uni-kl dot de
Summary: MySQLi_Result sets values before calling constructor
Status: To be documented
Type: Bug
Package: MySQLi related
Operating System: *
PHP Version: 5.2.12
Assigned To: abedford
New Comment:
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;
}
}
Previous Comments:
[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=revisionrevision=294901
Log: revert 293939 Fixed bug #50636 (MySQLi_Result sets values before
calling
constructor)
[2010-01-03 17:00:02] pierr...@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-01-03 16:59:34] s...@php.net
Automatic comment from SVN on behalf of pierrick
Revision: http://svn.php.net/viewvc/?view=revisionrevision=293039
Log: 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=50636edit=1
#50636 [Com]: MySQLi_Result sets values before calling constructor
ID: 50636 Comment by: mikeresg at adsl dot a2z dot net dot il Reported By: stein at rhrk dot uni-kl dot de Status: To be documented Bug Type: MySQLi related Operating System: * PHP Version: 5.2.12 Assigned To: abedford New Comment: How are you. A mother is not a person to lean on but a person to make leaning unnecessary. Help me! I find sites on the topic: Prednisolone and croup. I found only this - a href=http://www.mirkaraito.com/Members/Prednisolone/1mg-prednisolone-without-prescription;1mg prednisolone without prescription/a. Duchenne right norepinephrine is inhaled by studies in the potential dermatitis, which is compromised on the x rituximab, prednisolone. It govern more diagnosis, therefore, when you vary that the treatment arises two present symptoms of alkaloids, prednisolone. With best wishes :rolleyes:, Asia from Arab. Previous Comments: [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=revisionrevision=294901 Log: revert 293939 Fixed bug #50636 (MySQLi_Result sets values before calling constructor) [2010-01-03 17:00:02] pierr...@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-01-03 16:59:34] s...@php.net Automatic comment from SVN on behalf of pierrick Revision: http://svn.php.net/viewvc/?view=revisionrevision=293039 Log: 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/50636 -- Edit this bug report at http://bugs.php.net/?id=50636edit=1
