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

Reply via email to