Re: Bug #1452 Updated: $i = $i++ fails
| From: | Zeev Suraski | Date: | Wed, 26 May 1999 05:11:53 +0000 |
| Subject: | Re: Bug #1452 Updated: $i = $i++ fails | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-6008@lists.php.net to get a copy of this message | ||
At 03:49 26/05/99 , Colin Putney wrote:
Rasmus Lerdorf wrote:I don't consider $i=$i++ being $i++ any more correct than being nothing, and definitely don't see any robustness issues here. The way PHP works brings it to always be equivalent to nothing, and there's no reason to change that, whether it's easy or not (and no, it's not easy, but even if it were, I wouldn't support it). Zeev -- Zeev Suraski <zeev@zend.com> http://www.zend.com/ For a PGP public key, finger bourbon@netvision.net.il -- PHP Development Mailing List http://www.php.net/ To unsubscribe send an empty message to php-dev-unsubscribe@lists.php.net For help: php-dev-help@lists.php.netWell, I am not sure I agree with me. I was more suggesting that the original person was not completely out to lunch as Zeev originally made it sound. I have no problems leaving the current PHP behaviour be. I guess I should have been a little more clear about what I was agreeing with. The original bug report stated that PHP behaved differently than C. Zeev pointed out that this is not the case, as C's behaviour is undefined, whereas PHP at least behaves consistently. Fair enough. Your comment brought up the point that, to a programmer, $i = $i++ has a well defined meaning: $i = $i; $i = $i + 1; Presumably, C doesn't define the order which assigment operands are evaluated for a reason - to allow the compiler some flexibility in optimizing for a particular architecture. Well and good. But PHP only has one implementation, and you guys can define both the semantics of the language and the behaviour of the interpreter (or compiler as with Zend) however you want. My question was not entirely rhetorical. Is there a reason to choose the current behaviour (which is counter-intuitive and can lead to bugs in programs which are not well written) over the alternative (where PHP behaves as expected)? There may well be. Performance or cleanness of implementation are excellent reasons. If it were a lot of work to change, that would be a good reason. I don't have enough experience to judge. But if it makes no difference, why not make PHP that little bit more robust, even in goofy cases like this?I'm afraid I have to agree with Rasmus here. Laying aside the fact that it's undefined in C and a silly thing to do in the first place, is there any reason for PHP to adopt the former case rather than the later?