note 85015 deleted from language.oop5.overloading by danielc

From: 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.

« previous php.notes (#159972) next »