Req #28261 [Com]: Lifting reserved keyword restriction for method names
Edit report at https://bugs.php.net/bug.php?id=28261edit=1 ID: 28261 Comment by: swivelgames at gmail dot com Reported by:Philippe dot Jausions at 11abacus dot com Summary:Lifting reserved keyword restriction for method names Status: Open Type: Feature/Change Request Package:Scripting Engine problem Operating System: * PHP Version:* Block user comment: N Private report: N New Comment: 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! Previous Comments: [2013-08-12 09:48:08] 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. [2012-11-30 12:26:23] 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! [2012-11-02 22:17:55] 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-09-06 17:40:34] rayro at gmx dot de It would be nice to see this in future releases! [2011-08-08 16:13:17] 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. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=28261 -- Edit this bug report at https://bugs.php.net/bug.php?id=28261edit=1
Req #28261 [Com]: Lifting reserved keyword restriction for method names
Edit report at https://bugs.php.net/bug.php?id=28261edit=1 ID: 28261 Comment by: general-purpose at yandex dot ru Reported by:Philippe dot Jausions at 11abacus dot com Summary:Lifting reserved keyword restriction for method names Status: Open Type: Feature/Change Request Package:Scripting Engine problem Operating System: * PHP Version:* Block user comment: N Private report: N New Comment: Given that keyword named methods are working just fine already, there are now reason to forbid declaring them this way. +1 for fixing this. Previous Comments: [2012-11-30 12:26:23] 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! [2012-11-02 22:17:55] 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-09-06 17:40:34] rayro at gmx dot de It would be nice to see this in future releases! [2011-08-08 16:13:17] 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. [2011-07-26 15:56:42] info at strictcoding dot co dot uk +1 for this feature request! The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=28261 -- Edit this bug report at https://bugs.php.net/bug.php?id=28261edit=1
Req #28261 [Com]: Lifting reserved keyword restriction for method names
Edit report at https://bugs.php.net/bug.php?id=28261edit=1 ID: 28261 Comment by: florinpatan at gmail dot com Reported by:Philippe dot Jausions at 11abacus dot com Summary:Lifting reserved keyword restriction for method names Status: Open Type: Feature/Change Request Package:Scripting Engine problem Operating System: * PHP Version:* Block user comment: N Private report: N New Comment: 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! Previous Comments: [2012-11-02 22:17:55] 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-09-06 17:40:34] rayro at gmx dot de It would be nice to see this in future releases! [2011-08-08 16:13:17] 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. [2011-07-26 15:56:42] info at strictcoding dot co dot uk +1 for this feature request! [2011-07-10 19:47:43] s...@php.net The patch seems not to work with tokenizer extension - the extension returns wrong tokens (T_EVAL instead of expected T_STRING). The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=28261 -- Edit this bug report at https://bugs.php.net/bug.php?id=28261edit=1
Req #28261 [Com]: Lifting reserved keyword restriction for method names
Edit report at https://bugs.php.net/bug.php?id=28261edit=1 ID: 28261 Comment by: nathan dot goulding+phpbugs at gmail dot com Reported by:Philippe dot Jausions at 11abacus dot com Summary:Lifting reserved keyword restriction for method names Status: Open Type: Feature/Change Request Package:Scripting Engine problem Operating System: * PHP Version:* Block user comment: N Private report: N New Comment: 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. Previous Comments: [2012-09-06 17:40:34] rayro at gmx dot de It would be nice to see this in future releases! [2011-08-08 16:13:17] 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. [2011-07-26 15:56:42] info at strictcoding dot co dot uk +1 for this feature request! [2011-07-10 19:47:43] s...@php.net The patch seems not to work with tokenizer extension - the extension returns wrong tokens (T_EVAL instead of expected T_STRING). [2009-06-30 05:52:23] 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. JS::include(FILE_PATH)-include(FILE_PATH2)-include(FILE_PATH3); having method name other than include() is pretty annoying. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=28261 -- Edit this bug report at https://bugs.php.net/bug.php?id=28261edit=1
Req #28261 [Com]: Lifting reserved keyword restriction for method names
Edit report at https://bugs.php.net/bug.php?id=28261edit=1
ID: 28261
Comment by: rayro at gmx dot de
Reported by:Philippe dot Jausions at 11abacus dot com
Summary:Lifting reserved keyword restriction for method
names
Status: Open
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: *
PHP Version:*
Block user comment: N
Private report: N
New Comment:
It would be nice to see this in future releases!
Previous Comments:
[2011-08-08 16:13:17] 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.
[2011-07-26 15:56:42] info at strictcoding dot co dot uk
+1 for this feature request!
[2011-07-10 19:47:43] s...@php.net
The patch seems not to work with tokenizer extension - the extension returns
wrong
tokens (T_EVAL instead of expected T_STRING).
[2009-06-30 05:52:23] 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.
JS::include(FILE_PATH)-include(FILE_PATH2)-include(FILE_PATH3);
having method name other than include() is pretty annoying.
[2007-12-16 00:46:09] 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.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=28261
--
Edit this bug report at https://bugs.php.net/bug.php?id=28261edit=1
Req #28261 [Com]: Lifting reserved keyword restriction for method names
Edit report at https://bugs.php.net/bug.php?id=28261edit=1
ID: 28261
Comment by: steven_nikkel at ertyu dot org
Reported by:Philippe dot Jausions at 11abacus dot com
Summary:Lifting reserved keyword restriction for method
names
Status: Open
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: *
PHP Version:*
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
[2011-07-26 15:56:42] info at strictcoding dot co dot uk
+1 for this feature request!
[2011-07-10 19:47:43] s...@php.net
The patch seems not to work with tokenizer extension - the extension returns
wrong
tokens (T_EVAL instead of expected T_STRING).
[2009-06-30 05:52:23] 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.
JS::include(FILE_PATH)-include(FILE_PATH2)-include(FILE_PATH3);
having method name other than include() is pretty annoying.
[2007-12-16 00:46:09] 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.
[2007-10-05 02:13:49] cel...@php.net
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:
?php
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:
http://pear.php.net/~greg/smarter_lexer.patch.txt
Patch for PHP 6:
http://pear.php.net/~greg/php6_smarter_lexer.patch.txt
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=28261
--
Edit this bug report at https://bugs.php.net/bug.php?id=28261edit=1
Req #28261 [Com]: Lifting reserved keyword restriction for method names
Edit report at https://bugs.php.net/bug.php?id=28261edit=1
ID: 28261
Comment by: info at strictcoding dot co dot uk
Reported by:Philippe dot Jausions at 11abacus dot com
Summary:Lifting reserved keyword restriction for method
names
Status: Open
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: *
PHP Version:*
Block user comment: N
Private report: N
New Comment:
+1 for this feature request!
Previous Comments:
[2011-07-10 19:47:43] s...@php.net
The patch seems not to work with tokenizer extension - the extension returns
wrong
tokens (T_EVAL instead of expected T_STRING).
[2009-06-30 05:52:23] 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.
JS::include(FILE_PATH)-include(FILE_PATH2)-include(FILE_PATH3);
having method name other than include() is pretty annoying.
[2007-12-16 00:46:09] 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.
[2007-10-05 02:13:49] cel...@php.net
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:
?php
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:
http://pear.php.net/~greg/smarter_lexer.patch.txt
Patch for PHP 6:
http://pear.php.net/~greg/php6_smarter_lexer.patch.txt
[2004-05-04 18:18:05] he...@php.net
That's simply impossible.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=28261
--
Edit this bug report at https://bugs.php.net/bug.php?id=28261edit=1
