Req #73608 [Com]: inconstistent const behavior

Edit report at https://bugs.php.net/bug.php?id=73608&edit=1 ID: 73608 Comment by: dave at mudsite dot com Reported by: spam2 at rhsoft dot net Summary: inconstistent const behavior Status: Open Type: Feature/Change Request Package: Scripting Engine problem PHP Version: 7.0.13 Block user comment: N Private report: N New Comment: "how does that change the fact that in case of "if($x == 1)" you have no idea at compile time if $x will be 1" Well, you have to take a look to the grammar. It, as well as the compiler, are written pretty abstractly. The actual grammar of an if() statement is: T_IF '(' expr ')' statement You'd then look to expr, and see that it encompasses MANY types of expressions. For example, function calls are an expression. So we can take your example and rewrite it as such: $fp = fopen('/dev/urandom'); if (fread($fp, 2) == "no") [ const FOO = 'bar'; } In your basic example it's simple to mentally think $x is 1, 1 is 1, 1==1 why is this hard? Well again, it's abstract, so what is the first 2 characters of the filehandle here? At compile time, we would have no idea, so we would have no clue if that path should be taken or not. "either my sample would be invalid code and needs to be a fatal/compile/whatever error or you can use const with variables" It's not invalid code and needs no error. There's a disjoint between compiling syntax, and executing operations. The compiler takes your code and compiles it into opcodes that a virtual machine can execute over. To show you what the VM syntax looks like here's a very simple example. <?php $x = 1; var_dump($x); compiled vars: !0 = $x line #* E I O op fetch ext return operands ------------------------------------------------------------------------------------- 3 0 E > ASSIGN !0, 1 4 1 INIT_FCALL 'var_dump' 2 SEND_VAR !0 3 DO_ICALL 6 4 > RETURN 1 You can see that the compiler has converted the code into a set of 5 operations, using 1 compiled variable. The first op sets the value of the CV to 1, begin function call, send a variable denoted by the memory of the compiled-variable(!!), run the call, and return default(1). You can see that the compiler doesn't know the value of the compiled variable when it creates the opcode sending the value to the function, rather, it sends the location that stores the value. To get a better understanding of -why- this is important. <?php $x = rand(0, 1); var_dump($x); compiled vars: !0 = $x line #* E I O op fetch ext return operands ------------------------------------------------------------------------------------- 3 0 E > INIT_FCALL 'rand' 1 SEND_VAL 0 2 SEND_VAL 1 3 DO_ICALL $1 4 ASSIGN !0, $1 4 5 INIT_FCALL 'var_dump' 6 SEND_VAR !0 7 DO_ICALL 6 8 > RETURN 1 Here we end up doing a function call to rand, and take the return value of that setting it to the memory location of !0($x). So we don't know at compile time if a compiled variable contains a known value or a variable value, since we need to do things quite abstractly. Previous Comments: ------------------------------------------------------------------------ [2016-12-13 23:50:55] spam2 at rhsoft dot net or to make it very clear, the following code wrks just fine with PHP 7.0 and respects if it is running via CLI or not - in real life - rh_serverurl . MY_PHP_SELF - you have no idea at compile time which valkue both will have BUT it works if(PHP_SAPI != 'cli') { define('MY_PHP_SELF', $_SERVER['SCRIPT_NAME']); define('rh_serverurl', PROTOCOL_PREFIX . MY_SERVER_NAME . $rh_port); } else { define('MY_PHP_SELF', '/' . basename($_SERVER['SCRIPT_NAME'])); define('rh_serverurl', 'http://localhost'); } const rh_phpself = rh_serverurl . MY_PHP_SELF; ------------------------------------------------------------------------ [2016-12-13 23:47:21] spam2 at rhsoft dot net how does that change the fact that in case of "if($x == 1)" you have no idea at compile time if $x will be 1 - either my sample would be invalid code and needs to be a fatal/compile/whatever error or you can use const with variables the point is the damned function call for define() which means 15 define() calls are 0.2% runtime of our complete core-application while you can assign thounsands of variables in the same runtime but well, they are variables which can be changed and are not visible in every scope without additional opcodes $GLOBALS or global $foo; ------------------------------------------------------------------------ [2016-12-13 23:19:49] dave at mudsite dot com Yes I did see your example, and tried to expand upon it highlighting the use of runtime. To specifically address your (desired) example: <?php $x = 1; if($x == 1) { const CONST_A = 'A'; } We must read this to say that we wish to define a constant based on a variable expression. During compilation the compiler does not know what the value of any compiled-variable is, rather it knows how to look for the value during execution. So understanding that we can look at the if statement and see that we compare the equality of compiled-variable($x) and a constant(1). Only during execution will the result of that equality be known. Taking your example to the next logical example to showcase why it's not possible we have: <?php $x = 2; if ($x == 1) { const CONST_A = 'A'; } else { const CONST_A = 'AAA'; } Knowing that const is a compile-time portion of the grammar, how can we properly compile this example? We can't very well set a constant to two values, nor can we know which constant to compile. This is why "because it's compile time" is not a lie. Enter define(). As you show in your example it's the proper way to update the constant-table during runtime when variable-expressions can be evaluated to know which branch of code will be executed. <?php $x = 2; if ($x == 1) { define('CONST_A', 'A'); } else { define('CONST_A', 'AAA'); } ------------------------------------------------------------------------ [2016-12-13 16:17:40] spam2 at rhsoft dot net did you look at my example? const CONST_B = 'TEST ' . CONST_A; *works* here and since one part (CONST_A) of it is inside a if-statement how can that be when "a constant can not be variable" ------------------------------------------------------------------------ [2016-12-13 15:10:25] dave at mudsite dot com "because it's compile time" does not appear to exactly be a lie. The const keyword wants to be used (as is declared in the grammar) as a top-level statement. Why? Well a constant is compiled as a left, or right, node to op-codes at compile time, and therefore needs to be a literal constant. Now, imagine this code: <?php class Foo { function __toString() { return "I'm a FOO"; } } $f = new Foo(); const CONST_A = $f; const CONST_B = 'TEST ' . CONST_A; echo CONST_B . "\n"; ?> You would get a compilation fatal here as well, since a constant can not be a variable. define() however, is a runtime function that can accept variables and update the constant table with a reference to that compiled-variable(here that's an object). So looking again at your example, you're using the const-keyword within a statement dependent on a variable, therefore the value of a constant expression is variable, and a constant can not be variable. So if you want to define a constant that is variable, you have use of define() to do it at runtime. That said, just moving the grammar for T_CONST from top_statement into statement does get your code to run; however, I imagine the desire to keep const's out of places dependent on variables is the languages desire. Any internals people could feel free to correct my thoughts here. ------------------------------------------------------------------------ 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=73608 -- Edit this bug report at https://bugs.php.net/bug.php?id=73608&edit=1