#38636 [Opn->Bgs]: overloading __set changes the behavior of property access to call __get

From: Date: Tue, 29 Aug 2006 07:39:41 +0000
Subject: #38636 [Opn->Bgs]: overloading __set changes the behavior of property access to call __get
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-101472@lists.php.net to get a copy of this message
ID: 38636 Updated by: tony2001@php.net Reported By: foobar at dodgeit dot com -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: FreeBSD 6.1 PHP Version: 5.1.5 New Comment: Expected behaviour. Since there is no __set(), you created a "real" property with $a->foo = 'foo';, and __get() is called only for "virtual" properties. Previous Comments: ------------------------------------------------------------------------ [2006-08-29 01:07:03] foobar at dodgeit dot com Sorry, I reversed expected and actual results. ------------------------------------------------------------------------ [2006-08-29 01:03:52] foobar at dodgeit dot com Description: ------------ Consider the following code: $foo = new A; $foo->bar = 'bar'; echo $foo->bar; Assume A defines __get. Behavior of the last line is different depending on whether A defines __set. If __set is not defined, then the last line won't call __get. If __set is defined, __get will be called. Reproduce code: --------------- <?php class A { public function __get($prop) { echo "getting\n"; } } $a = new A; $a->foo = 'foo'; echo $a->foo."\n"; ?> ------ <?php class A { public function __get($prop) { echo "getting\n"; } public function __set($prop, $val) { echo "setting\n"; } } $a = new A; $a->foo = 'foo'; echo $a->foo."\n"; ?> Expected result: ---------------- The first run produces: foo The second run produces: getting setting Actual result: -------------- Either 'getting' should be printed in both runs, or it should be not printed in either run. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=38636&edit=1

« previous php.bugs (#101472) next »