Re: Bug #1248: operator ? : has wrong associativity (has left, should be right).

From: Date: Sat, 20 Mar 1999 23:57:29 +0000
Subject: Re: Bug #1248: operator ? : has wrong associativity (has left, should be right).
References: 1 2  Groups: php.dev 
Request: Send a blank email to php-dev+get-4702@lists.php.net to get a copy of this message
On Sun, Mar 21, 1999 at 01:34:16AM +0000, Zeev Suraski wrote: > This kind of depends on the language definition of PHP. It's true that > right-associativity would be compatible with C's associativity rules, but > that's all it is. I'm not sure if it's worth it to change this > associativity rule at this point; people may have relied on it, and it's > not a bug in any way. Well i might agree with the fact that now it is too late. Anyways it is kind of unfortunate to redefine the meaning (=associativity) of "standard" operator. > And on a related note, you should *really* be using > parentheses instead of relying on the precedence rules of any of the > non-trivial operators. Well i wouldnt agree here .. it is questionable what is trivial operator and what is not. I believe it comes from C so i expect it to work that way (same in perl and resemblance to perl is quite appealing). Of course it is legitimate to redefine any operator to behave in any way in a new language, but I believe it wasnt your (or whoever wrote language parser) intention to define it this way. Anyways, you are right .. at this moment there arent any options left. One way would be modify the parser to be able to set the associativity at run time and have it configurable in config file or runtime directive. This could lead to reduced portability but my guess is, that those who write nested ?: operators know it from previous languages so they have to use parents anyways so it wouldnt hurt them. Thanks for reply, Peter -- Peter Kundrat kundrat@general-it.sk -- 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.net

« previous php.dev (#4702) next »