note 85015 deleted from language.oop5.overloading by danielc
| From: | danielc@php.net | Date: | Fri, 28 Aug 2009 03:37:24 +0000 |
| Subject: | note 85015 deleted from language.oop5.overloading by danielc | ||
| References: | 1 | Groups: | php.notes |
| Request: | Send a blank email to php-notes+get-159972@lists.php.net to get a copy of this message | ||
Note Submitter: me at ben-xo dot com
Reason: 0
----
uramihsayibok is correct that PHP diverges from what one would expect based on experiences with
other programming languages.
It's a C-ism that the action of assignment, such as $b=$a, is actually a *function* (that has a
return value) and in a mathsy, set-theory kind of way, that makes perfect sense. So, when you see
$c=$b=$a, you should actually read it as ($c=($b=$a)), as that's where the brackets are
grouped. $c is assigned with the return value of ($b=$a), and that return value is the value of the
assignment. It's really just 'syntactic sugar' that assignment is written in DEST =
SOURCE format (this is known as 'infix notation') rather than =(DEST, SOURCE), which would
be valid in some other languages (this is known as 'prefix notation').
PHP does not provide access to the assignment function directly, nor does it allow for operator
overriding (if you want to do that sort of magic, try Ruby!) so one can safely assume that the
semantics of assignment have been optimised in such a way that __set() is NOT actually overriding
assignment, just acting as a pre-commit hook, which is different from how it's implemented in
other languages.
Conclusion: __set may appear to override the assignment operator on an object, but BEWARE as
that's not what it's actually doing.