Jessie Hernandez schrieb: >>> that's only one case,go with consts. now try >>>$x = $y ? foo:bar:baz:stupid; >>[... my two cents...]
> Thank you!!! This is exactly what happens with my patch now in this > case, one constant named "foo:bar:baz:stupid" is parsed and a syntax > error is produced because of a missing colon and third argument. So, for > this to be interpreted right, a space must be added after "foo:bar" at > the very least (alternatively, use parentheses). This is simply a side > effect of the implementation, but it can actually be considered a > _feature_, since it promotes code clarity in this instance (again, this > only happens and is only required in this ONE instance). Well, then again: There's still the difference between : and :: . (intended whitespace inserted in front of the period *g*) So if one only allows simple namespaces (no nesting), then one can see that this need to be two namespace constants BUT one has to read the whole line: - one colon means simple constants - three colons: two namespaces constants - two colons: ERROR, undefined My opinion: Throw a parser error for missing third argument and enforce using parentheses. Not allowing constants in namespaces would mean that the current PHP core could not be put inside a "PHP" namespace because (guess what) it contains global constants. OLLi PS: How about a unicode symbol (egypt god Ra) as namespace operator. PHP6 will be all about unicode => Yeah, gazillions of new operator symbols. Or register a "PHP namespace separator symbol" that looks like the PHP logo. Just kidding... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
