|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #28261 Lifting reserved keyword restriction for method names
Submitted: 2004-05-03 17:36 UTC Modified: 2016-01-16 13:25 UTC
Avg. Score:4.5 ± 1.0
Reproduced:54 of 54 (100.0%)
Same Version:32 (59.3%)
Same OS:35 (64.8%)
From: Philippe dot Jausions at 11abacus dot com Assigned: danack (profile)
Status: Closed Package: Scripting Engine problem
PHP Version: * OS: *
Private report: No CVE-ID: None
 [2004-05-03 17:36 UTC] Philippe dot Jausions at 11abacus dot com

Wouldn't it be possible to lift the reserved keyword restriction for method names?

It seems to me that there shouldn't be any namespace conflict with the core PHP language.

Reproduce code:

class a {
   function eval() {
      // Do something...


Actual result:
Parse error: parse error, unexpected T_EVAL, expecting T_STRING


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2004-05-04 18:18 UTC]
That's simply impossible.
 [2007-10-05 02:13 UTC]
as new reserved words are introduced, they tend to clash with existing class's method names.  import and namespace are particularly nasty examples of methods that are likely to clash, although I have also run into problems with "list" which is a very nice method name for many tasks.

The patches linked to in this comment provides a simple and effective means of allowing reserved words in method names.  Not only is it possible, but it is quite elegant :).

It also fixes, as a side effect, a bug in the parsing of this code:

class A {
var $list;
$a = new A;
$a->list = 1;
$a-> list = 2; // parse error, unexpected T_LIST

whitespace between T_OBJECT_OPERATOR and the variable name changes the token returned from T_STRING to any valid token.

Patch for PHP 5:
Patch for PHP 6:
 [2007-12-16 00:46 UTC] kentfredric at gmail dot com
At the moment (5.2.3 ) this is perfectly valid.

Class A{
  function __call( $function, $args ){
     if( $function == 'print' ){
        print "MyPrint: {$args[0]}";
$a = new A();
$a->print( "hello" ); #<-- surprisingly, this is not an invalid use of a keyword to the lexer. 
  # >> MyPrint: hello

but this

Class A{
  function print( $args ){
        print "MyPrint: {$args}";
$a = new A();
$a->print( "hello" );

Yields a parse error "Parse error: syntax error, unexpected T_PRINT, expecting T_STRING"

which appears to be an illogical design contstraint. 

I've seen rather brutal slander for people attempting to perform this ( #14178 , this bug ) amounting to "hey, you suck, dont do that" without any rational explanation.

So yes, I look forward to this feature being integrated.
 [2009-06-30 05:52 UTC] taufiq at krimnet dot com
I need this bug to be resolved.

I'm writing Javascript/CSS collector & minify library. 

I would like to code like below.


having method name other than include() is pretty annoying.
 [2011-04-08 21:16 UTC]
-Package: Feature/Change Request +Package: Scripting Engine problem -PHP Version: 6CVS, 5CVS +PHP Version: *
 [2011-07-10 19:47 UTC]
The patch seems not to work with tokenizer extension - the extension returns wrong 
tokens (T_EVAL instead of expected T_STRING).
 [2011-07-26 15:56 UTC] info at strictcoding dot co dot uk
+1 for this feature request!
 [2011-08-08 16:13 UTC] steven_nikkel at ertyu dot org
Would this prevent the keyword eval from being used within code being eval'd?

That appears to be the bug I'm running into, even though the keyword is only used in contained javascript code, not php, even included as a comment it fails.
 [2012-09-06 17:40 UTC] rayro at gmx dot de
It would be nice to see this in future releases!
 [2012-11-02 22:17 UTC] nathan dot goulding+phpbugs at gmail dot com
I agree that this is worthwhile and should be fixed. Ridiculing this suggestion 
(#14178 and #10743) are unfortunate and I haven't seen a well-reasoned argument 
why this is so awful. Hoping this eleven line patch can get integrated soon.
 [2012-11-30 12:26 UTC] florinpatan at gmail dot com
There are some libraries out there like AMQP/Gearman who have reserved keywords as method names and while they work just fine, it's impossible to extend them and overwrite those methods as the parser would just fail.

While this is a known issue, with more and more PHP keywords being added and with PHP 5 promoting itself as being a OOP seasoned language, I see no reason for methods in class names to be so restricted.

Thank you!
 [2013-08-12 09:48 UTC] general-purpose at yandex dot ru
Given that keyword named methods are working just fine already, there are now reason to forbid declaring them this way. +1 for fixing this.
 [2013-08-18 04:41 UTC] swivelgames at gmail dot com
Absolutely agree. I've run into many instances where this would have been useful. 
Seems almost trivial why this is even needed as a feature request, honestly. 
Really hope this bug gets fixed soon :) Thanks for taking care of this guys!
 [2014-02-03 16:59 UTC] chris dot baker dot gr at gmail dot com
10 years on from the original feature request, 7 years on from a workable patch, and I still can't make a class with a method named "list". I hate to be snarky, but come on guys. With other feature requests favored by spaghetti CMS author groups landing on a fast track, can we get this core OOP concept fixed for the rest of us?
 [2015-01-08 22:56 UTC]
There was an RFC for this that was rejected. Might be more possible now, especially with the AST.
 [2016-01-16 13:25 UTC]
-Status: Open +Status: Closed -Assigned To: +Assigned To: danack
 [2016-01-16 13:25 UTC]
This was mostly fixed for PHP 7:

class a {
   function eval() {
      // Do something...

echo "fin.";

For any other reserved words, a new RFC will need to be made.
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Thu Jun 30 23:03:49 2022 UTC