Good evening all!
Currently, if the constant FROB_ACTIVE is not defined, the code "echo
FROB_ACTIVE;" results in an E_NOTICE and the string 'FROB_ACTIVE' being
displayed. I would like to propose that this be changed to an E_WARNING
in PHP 7.2, and to an Error in PHP 8.0.
My reasoning for this includes:
- consistency with other "undefined" errors, including the otherwise
identical "echo \FROB_ACTIVE;" - the fallback to string appears to be largely undocumented except to
discourage its use - the error can mask serious bugs, such as when mis-typing keywords
I have tried to anticipate some of the questions that will be raised, so
have drafted an RFC rather than trying to fit all the detail into one
e-mail: https://wiki.php.net/rfc/deprecate-bareword-strings
Please read my proposal, and let me know your thoughts. I have placed
the RFC "under discussion", but will be happy to modify it based on
feedback, and am in no haste to put it to a vote.
Regards,
--
Rowan Collins
[IMSoP]
2017-01-29 20:33 GMT+01:00 Rowan Collins rowan.collins@gmail.com:
Good evening all!
Currently, if the constant FROB_ACTIVE is not defined, the code "echo
FROB_ACTIVE;" results in anE_NOTICEand the string 'FROB_ACTIVE' being
displayed. I would like to propose that this be changed to anE_WARNINGin
PHP 7.2, and to an Error in PHP 8.0.My reasoning for this includes:
- consistency with other "undefined" errors, including the otherwise
identical "echo \FROB_ACTIVE;"- the fallback to string appears to be largely undocumented except to
discourage its use- the error can mask serious bugs, such as when mis-typing keywords
I have tried to anticipate some of the questions that will be raised, so
have drafted an RFC rather than trying to fit all the detail into one
e-mail: https://wiki.php.net/rfc/deprecate-bareword-stringsPlease read my proposal, and let me know your thoughts. I have placed the
RFC "under discussion", but will be happy to modify it based on feedback,
and am in no haste to put it to a vote.Regards,
--
Rowan Collins
[IMSoP]--
I think it should emit an E_DEPRECATED instead of E_WARNING, but otherwise
+1.
On Sun, Jan 29, 2017 at 8:33 PM, Rowan Collins rowan.collins@gmail.com
wrote:
Good evening all!
Currently, if the constant FROB_ACTIVE is not defined, the code "echo
FROB_ACTIVE;" results in anE_NOTICEand the string 'FROB_ACTIVE' being
displayed. I would like to propose that this be changed to anE_WARNINGin
PHP 7.2, and to an Error in PHP 8.0.My reasoning for this includes:
- consistency with other "undefined" errors, including the otherwise
identical "echo \FROB_ACTIVE;"- the fallback to string appears to be largely undocumented except to
discourage its use- the error can mask serious bugs, such as when mis-typing keywords
I have tried to anticipate some of the questions that will be raised, so
have drafted an RFC rather than trying to fit all the detail into one
e-mail: https://wiki.php.net/rfc/deprecate-bareword-stringsPlease read my proposal, and let me know your thoughts. I have placed the
RFC "under discussion", but will be happy to modify it based on feedback,
and am in no haste to put it to a vote.
Fully agree with this proposal.
Also agree with the choice of throwing a Warning instead of a Deprecation.
Throwing a Deprecation would essentially downgrade the current error
level, which does not appear to be prudent.
Nikita
On Sun, Jan 29, 2017 at 8:33 PM, Rowan Collins rowan.collins@gmail.com
wrote:Good evening all!
Currently, if the constant FROB_ACTIVE is not defined, the code "echo
FROB_ACTIVE;" results in anE_NOTICEand the string 'FROB_ACTIVE' being
displayed. I would like to propose that this be changed to anE_WARNINGin
PHP 7.2, and to an Error in PHP 8.0.My reasoning for this includes:
- consistency with other "undefined" errors, including the otherwise
identical "echo \FROB_ACTIVE;"- the fallback to string appears to be largely undocumented except to
discourage its use- the error can mask serious bugs, such as when mis-typing keywords
I have tried to anticipate some of the questions that will be raised, so
have drafted an RFC rather than trying to fit all the detail into one
e-mail: https://wiki.php.net/rfc/deprecate-bareword-stringsPlease read my proposal, and let me know your thoughts. I have placed the
RFC "under discussion", but will be happy to modify it based on feedback,
and am in no haste to put it to a vote.Fully agree with this proposal.
Also agree with the choice of throwing a Warning instead of a Deprecation.
Throwing a Deprecation would essentially downgrade the current error
level, which does not appear to be prudent.Nikita
I also agree with the choice of throwing a Warning instead of a
Deprecation. I'll be happy to see this feature removed. Good riddance!
Currently, if the constant FROB_ACTIVE is not defined, the code "echo
FROB_ACTIVE;" results in anE_NOTICEand the string 'FROB_ACTIVE' being
displayed. I would like to propose that this be changed to anE_WARNING
in PHP 7.2, and to an Error in PHP 8.0.My reasoning for this includes:
- consistency with other "undefined" errors, including the otherwise
identical "echo \FROB_ACTIVE;"- the fallback to string appears to be largely undocumented except to
discourage its use- the error can mask serious bugs, such as when mis-typing keywords
I have tried to anticipate some of the questions that will be raised, so
have drafted an RFC rather than trying to fit all the detail into one
e-mail: https://wiki.php.net/rfc/deprecate-bareword-stringsPlease read my proposal, and let me know your thoughts. I have placed
the RFC "under discussion", but will be happy to modify it based on
feedback, and am in no haste to put it to a vote.
Thanks for bringing this forward, Rowan!
I'm +1 on the proposal by all accounts.
--
Christoph M. Becker
Great! We can get rid of one of the most ridiculed "features" of the
language :D
http://php.net/manual/en/language.types.array.php#language.types.array.donts
"This is wrong, but it works."
Simply +1 this is a ridiculous feature which never made sense in the
first place. Also +1 for E_WARNING and removal of complete support in
PHP 8.0.
--
Richard "Fleshgrinder" Fussenegger
have drafted an RFC rather than trying to fit all the detail into one e-mail: https://wiki.php.net/rfc/deprecate-bareword-strings
Please read my proposal, and let me know your thoughts. I have placed the RFC "under discussion", but will be happy to modify it based on feedback, and am in no haste to put it to a vote.
Happy to see this behavior removed, and appreciate the incremental approach. E_WARNING seems appropriate. Thanks for proposing it!
--
Paul M. Jones
pmjones88@gmail.com
http://paul-m-jones.com
Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp
Solving the N+1 Problem in PHP
https://leanpub.com/sn1php
Hi,
Currently, if the constant FROB_ACTIVE is not defined, the code "echo
FROB_ACTIVE;" results in anE_NOTICEand the string 'FROB_ACTIVE'
being displayed. I would like to propose that this be changed to an
E_WARNINGin PHP 7.2, and to an Error in PHP 8.0.
related: There is another context where unquoted strings are used:
$a = [ "foo" => "bar" ];
echo "Let's go and have a drink in a $a[foo]!";
Any thoughts about continuing to allow that?
johannes
Hi,
Currently, if the constant FROB_ACTIVE is not defined, the code "echo
FROB_ACTIVE;" results in anE_NOTICEand the string 'FROB_ACTIVE'
being displayed. I would like to propose that this be changed to an
E_WARNINGin PHP 7.2, and to an Error in PHP 8.0.related: There is another context where unquoted strings are used:
$a = [ "foo" => "bar" ];
echo "Let's go and have a drink in a $a[foo]!";
Oh and there's another case:
foo.php?a[foo]=bar
Any thoughts about continuing to allow that?
I'm not saying we have to change those. But I believe the symmetry there
is part of the historic reason.
johannes
Currently, if the constant FROB_ACTIVE is not defined, the code "echo
FROB_ACTIVE;" results in anE_NOTICEand the string 'FROB_ACTIVE'
being displayed. I would like to propose that this be changed to an
E_WARNINGin PHP 7.2, and to an Error in PHP 8.0.related: There is another context where unquoted strings are used:
$a = [ "foo" => "bar" ];
echo "Let's go and have a drink in a $a[foo]!";
This is explicitly mentioned in the RFC's "Unaffected PHP Functionality"
section[1]. The RFC suggest to keep this shortcut.
Oh and there's another case:
foo.php?a[foo]=bar
Any thoughts about continuing to allow that?
I'm not saying we have to change those. But I believe the symmetry there
is part of the historic reason.
Okay, but in neither case you've mentioned there are any potential
pitfalls, i.e. foo can't be mistaken for a constant there, because the
engine expects an unquoted string.
[1]
https://wiki.php.net/rfc/deprecate-bareword-strings#unaffected_php_functionality
--
Christoph M. Becker
There is another context where unquoted strings are used:
$a = [ "foo" => "bar" ];
echo "Let's go and have a drink in a $a[foo]!";
This is explicitly mentioned in the RFC's "Unaffected PHP Functionality"
section[1]. The RFC suggest to keep this shortcut.
Indeed, thanks to whoever put that section in the RFC template. :)
I do think it is a rather odd syntax rule, and not one I would include
if designing PHP from scratch, particularly since putting single quotes
around the key...
echo "Let's go and have a drink in a $a['foo']!";
...results in a rather surprising error:
Parse error: syntax error, unexpected '' (T_ENCAPSED_AND_WHITESPACE),
expecting identifier (T_STRING) or variable (T_VARIABLE) or number
(T_NUM_STRING)
The most consistent interpretation would actually be for the [ to be
treated as just part of the string, which would never be a useful result:
Notice: Array to string conversion
Let's go and have a drink in a Array[foo]!
It's just possible that someone would expect "$message[E_WARNING]" to
look up the constant, but since it never does, this is less likely to
cause the kind of subtle bugs I describe in the RFC. Plus this syntax is
documented and recommended, whereas the one I propose to remove appears
to have never been either of those things.
Oh and there's another case:
foo.php?a[foo]=bar
I hadn't thought of that one; I'll add it to the RFC as also not
changing, for all the same reasons.
Indeed, this one has no ambiguity at all, since there is no scope where
constants could be defined in order to populate it.
I'm not saying we have to change those. But I believe the symmetry there
is part of the historic reason.
Unless Rasmus, Zeev, or Andy venture down memory lane and tell us
otherwise, I think that's a reasonable theory. The fallback is certainly
usually mentioned when talking about array keys, even though it applies
to any bare word the parser sees.
Regards,
Rowan Collins
[IMSoP]
Currently, if the constant FROB_ACTIVE is not defined, the code "echo
FROB_ACTIVE;" results in anE_NOTICEand the string 'FROB_ACTIVE'
being displayed. I would like to propose that this be changed to an
E_WARNINGin PHP 7.2, and to an Error in PHP 8.0.
[...]
https://wiki.php.net/rfc/deprecate-bareword-strings
Hi,
I have made some minor updates to the above RFC, and would like to open
it for voting in the next few days.
Changes since I first posted the RFC are:
-
Expanded the rationale for using
E_WARNINGrather than E_DEPRECATED. I
always anticipated this would be the most contentious part of the
proposal, but am convinced the peculiarities of the situation make this
the best choice. Please read that section carefully if you are
concerned, and let me know if anything remains unclear. -
Settled on a proposed wording for the new Warning. I spent some time
considering the best phrasing and punctuation, but if anyone would like
to suggest an improvement, I am open to feedback. -
Clarified the history of the feature, having successfully built PHP 2
from the archived source, and confirmed that bare words were a syntax
error. As such, no non-beta version of PHP allowed unquoted strings
without issuing a Notice. -
Added links to Pull Requests for both php-src and php-langspec to
implement the proposed wording. Amusingly, I had to change a test in
php-src which seems to have been accidentally using an unquoted
string; apparently, the configuration of that test is such that the
E_NOTICEwas suppressed.
Please let me know if there is any feedback I should take into
consideration before opening this to a vote.
Regards,
--
Rowan Collins
[IMSoP]