Sebastian Bergmann wrote (on 15/09/2014):
In any case, I think it would be best to build on the great work Nikita
did with the AST-based parser for PHP 7 and refactor the compiler to
allow reserved words as names for namespaces, classes, interfaces, ...
*before* we introduce new reserved words (and thus BC breaks).
Surely, in this case, the reserved word would have to be banned as a
class/interface name *anyway*, even if the parser generally allowed
reserved words there?
Otherwise the following is ambiguous:
class Int {
public function test(int $foo) {
// Is this function requiring an instance of class Int, or a
scalar of type int?
}
}
If the interpretation is as a class name, then defining that class
breaks all instances of scalar hinting everywhere in the current
execution. Not to mention how it would interact with autoloading,
reinterpreting already compiled functions, etc.
If the interpretation is as an int, then the BC break exists anyway,
because the keyword has to be "partially reserved", which is probably
more confusing than just reserving it.
I'm all for keeping the number of reserved words in a language down (cf
Douglas Crockford on why JSON requires quoting on all key names), but it
makes things very messy if you try not to have any at all.
--
Rowan Collins
[IMSoP]
