Doc #77100 [Asn->Csd]: Inconsistent behavior between constants and magic constants

From: Date: Mon, 05 Nov 2018 14:57:19 +0000
Subject: Doc #77100 [Asn->Csd]: Inconsistent behavior between constants and magic constants
References: 1  Groups: php.doc.bugs 
Request: Send a blank email to doc-bugs+get-16122@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=77100&edit=1 ID: 77100 Updated by: cmb@php.net Reported by: fabien dot villepinte at gmail dot com Summary: Inconsistent behavior between constants and magic constants -Status: Assigned +Status: Closed Type: Documentation Problem Package: Scripting Engine problem PHP Version: Irrelevant Assigned To: cmb Block user comment: N Private report: N New Comment: This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. Previous Comments: ------------------------------------------------------------------------ [2018-11-05 14:56:42] cmb@php.net Automatic comment from SVN on behalf of cmb Revision: http://svn.php.net/viewvc/?view=revision&revision=345954 Log: Fix #77100: Inconsistent behavior between constants and magic constants ------------------------------------------------------------------------ [2018-11-05 00:11:59] a at b dot c dot de That is consistent with variable names: just as you can create a variable that has a name impossible to use as a literal (e.g., ${"$"}) so too you can create a constant that can't be referred to literally. ------------------------------------------------------------------------ [2018-11-04 14:58:11] cmb@php.net @nikic Thanks! Changing to doc problem. ------------------------------------------------------------------------ [2018-11-04 12:44:05] nikic@php.net I'm inclined to mark this won't fix. Magic constants are just keywords that have syntactical similarity to constants. I don't think we have any business checking that constant names do not match keywords. If we forbid define('__DIR__'), should we also forbid define('function')? Ultimately everything here works just fine in the sense that you can define that constant and also look it up using constant(). You can't access it with constant syntax because the __DIR__ keyword takes precedence, but there's any number of other reasons why such an access may not be possible. For example, you can also do define('123', 'foo') and then access it using constant('123'), but for obvious reasons it will not change the behavior of directly writing 123 in code. ------------------------------------------------------------------------ [2018-11-04 11:21:23] cmb@php.net > I'd suggest prepopulating the constants table with them only I > don't know how something like constant('__LINE__') could work. Prepopulating the constants table would require to update it frequently during run time to be consistent with the compile time constants. Besides being inefficient, it would also change “constant” values. It might be preferable to not allow any of the predefined magic constants (or maybe all constant names with two leading and trailing underscores) to be used with define(), defined() and constant(). Either way would break BC, though. ------------------------------------------------------------------------ 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=77100 -- Edit this bug report at https://bugs.php.net/bug.php?id=77100&edit=1

« previous php.doc.bugs (#16122) next »