note 80898 added to language.oop5.overloading

Chained assignments are still right-associative and still work as expected. That is to say, $a = $foo->b = $c is equivalent to $a = ($foo->b = $c) and results in $a being set to the value of $c even if $foo->b is a property handled by __get/__set and even if those methods adjust/validate their arguments (and even if they fail). In other words, "$a = $b = $c;" and "$a = ($b = $c);" are both equivalent to "$a = $c; $b = $c;" and not to the equally plausible "$b = $c; $a = $b;". Assignment expressions evaluate to the value that gets assigned - the value that appears on the right-hand side - and what happens to whatever is on the left is treated as a side-effect. So in the expression $a=$b=$c, $a doesn't care about what does or doesn't happen to $b - all it sees is the *value* of $b=$c, which is just the value of $c. The parentheses make this clearer: in $a=($b=$c) we have $b being assigned the value of $c and $a being assigned the value of ($b=$c). As already hinted, this is nothing new: it's just made more obvious by __get and __set: $a = $foo->b = $c does NOT involve looking up the value of $foo->b (let alone assigning it to $a), and $foo->__get() isn't called. ---- Server IP: 203.89.181.186 Probable Submitter: 60.234.168.92 ---- Manual Page -- http://www.php.net/manual/en/language.oop5.overloading.php Edit -- https://master.php.net/note/edit/80898 Del: integrated -- https://master.php.net/note/delete/80898/integrated Del: useless -- https://master.php.net/note/delete/80898/useless Del: bad code -- https://master.php.net/note/delete/80898/bad+code Del: spam -- https://master.php.net/note/delete/80898/spam Del: non-english -- https://master.php.net/note/delete/80898/non-english Del: in docs -- https://master.php.net/note/delete/80898/in+docs Del: other reasons-- https://master.php.net/note/delete/80898 Reject -- https://master.php.net/note/reject/80898 Search -- https://master.php.net/manage/user-notes.php