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
