Stanislav Malyshev schrieb: > OG>>BUT the discussion is not only about possibility but also about what you > OG>>would like. The ":" for example would work if mandatory whitespace would > OG>>be introduced for the ternary BUT this is very very bad. > > If my vote is counted (not that I asked for it :) then I vote against all > funky syntax, present and future. :: is only thing that is obvious and > somehow connected to the world of PHP as we know it now.
Well, some people always keep throwing that already used symbols cannot be used for other purposes. :: is used for resolving class scope. Well, the tokenizer COULD be so smart as to look ahead but I still haven't heard from any developer if the tokenizer is able to do that or if its context only consists of "before the currently found symbol". And the of course, multicontext symbols mean less performance (I guess). For the proposed : and its conflict with the middle symbol of the ternary operator the problem is somehow similar: If the tokenizer reads the ? it's already clear that a ternary is "happening". Examples: $b=$a?c:d; Currently this means "$b gets the value of constant c or d depending on the value of $a". If : becomes the namespace operator and then this symbol would ordinarily have a higher operator precedence and the tokenizer would read "constant d in namespace c" and then not find the middle : of the ternary hence throwing a parse error. This is obviously very bad since such scripts might already exist. BUT if the tokenizer would have a higher precedence for the middle ternary then this would run as before. To use namespaces in the ternary one would the simply force to put them in parentheses which is no big problem since such cases might be EXTREMELY rare. This would work: $b=$a?(c:d):(e:f); but this would not: $b=$a?c:d:e:f; with an error of "; expected at the position of the second :" (if ignoring namespaces there completely) or "; expected at the position of the third;" (if namespaces kick in AFTER the middle ternary operator) or something like that which would both be tolerable. The only question that nobody answered until now: Is such a behaviour of the tokenizer possible or do such contextual decisions not even happen until AFTER the tokenizing process? If it could be done this way then this would be the way to go since everybody seems to like : and the only thing in the way is one extremely rare case. OLLi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php