Very good find of an inconsistency. Does the testsuite reveal something
strange with that patch?
Am 10.07.11 19:41 schrieb "Nikita Popov" unter <nikita....@googlemail.com>:
>Well, I generally think that PHP should be less strict about reserved
>keywords. The number
>of reserved keywords increases with every further release of PHP. For
>example PHP 5.4
>introduces "trait" and "insteadof". PHP 5.3 introduced even more. Every
>new
>keyword PHP
>introduces both breaks old code and reduces the naming possibilities for
>classes and methods.
>
>I don't think that it's possible to refrain from adding further keywords.
>The language grows and
>with it the list of keywords.
>
>But I do think that it should be possible to prevent these additions from
>breaking old code or
>restricting userland naming.
>
>E.g. Writing
>
>class Evaluator {
> public function eval() {
>
> }
>}
>
>Does in no way create an ambiguity with the eval language construct PHP
>implements.
>
>But still PHP doesn't allow writing the above code. It would make sense to
>allow the
>use of the keyword in such situations. Actually PHP already does this in
>one
>place:
>The token after T_OPJECT_OPERATOR is never interpreted as a keyword. I.e.
>one can
>write $this->eval() (and define a magic __call method for 'eval').
>
>I don't know whether this is actually possible, but I've at least already
>seen a patch
>(http://pear.php.net/~greg/smarter_lexer.patch.txt) for the methodname
>case
>linked
>from a feature request (https://bugs.php.net/bug.php?id=28261).
>
>MfG Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
