RE: [PHP-DEV] Re: [PHP-LANG] Approaching the First Draft [of a language spec]

On Tue, 21 Nov 2000, Zeev Suraski wrote: > I agree that the spec shouldn't document weird odds and ends that are > either bugs or misfeatures that we decide that should be fixed as a part of > the language (although it'd be a good thing to document these until they're > fixed). I just think that as a general rule, describing what exists, > rather than what *should* exist, is the way to go (there can be some > distance between the actual implementation and the spec, due to > bugs/misfeatures, but the distance should be very short). We will need to discuss the behaviour of the conditional operator. That issue has been touched multiple times in the past. I think this stage warrants reevaluating the facts though as we will define the behaviour once and for all. Fixing the behaviour of this operator will only affect constructs which have a certain degree of complexity. I.e. $cond = $foo ? $bar : $baz ? $john : $doe; It will not affect constructs with less complexity. A user who is capable of understanding and writing such complex constructs will notice that PHP's semantics don't reflect the standard behaviour of the operator. Therefore, the construct will be re-written as $cond = $foo ? $bar : ($baz ? $john : $doe); Hence, I'm arguing that a user (a) who is capable of deploying such constructs, and (b) understanding the effects will already have applied the proper work-around as layed out above. And thus, changing the semantics of the conditional operator will not affect backwards compatibility of existing scripts in a negative manner. Indeed, it will correct scripts which have been written in the assumption of right-associativity of the operator. This implies that there is no valid use of the current behaviour. I challenge everyone to come up with an example where the left-associativity of the operator is indeed useful. - Sascha