rfc:uniform_variable_syntax

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
rfc:uniform_variable_syntax [2014/06/06 15:57]
nikic
rfc:uniform_variable_syntax [2017/09/22 13:28] (current)
Line 2: Line 2:
   * Date: 2014-05-31   * Date: 2014-05-31
   * Author: Nikita Popov <nikic@php.net>   * Author: Nikita Popov <nikic@php.net>
-  * Status: Draft +  * Status: Implemented (in PHP 7) 
-  * Proposed forPHP 6+  * Discussionhttp://markmail.org/message/mr4ihbubfbdxygci
  
 ===== Introduction ===== ===== Introduction =====
Line 51: Line 51:
 <code php> <code php>
                         // old meaning            // new meaning                         // old meaning            // new meaning
-$$foo['bar']['baz'    ${$foo['bar']['baz'     ($$foo)['bar']['baz'+$$foo['bar']['baz'    ${$foo['bar']['baz']}     ($$foo)['bar']['baz'
-Foo::$bar['baz']()      Foo::{$bar['baz']}()      (Foo::$bar)['baz']()+$foo->$bar['baz'      $foo->{$bar['baz']}       ($foo->$bar)['baz']
 $foo->$bar['baz']()     $foo->{$bar['baz']}()     ($foo->$bar)['baz']() $foo->$bar['baz']()     $foo->{$bar['baz']}()     ($foo->$bar)['baz']()
 +Foo::$bar['baz']()      Foo::{$bar['baz']}()      (Foo::$bar)['baz']()
 </code> </code>
  
Line 69: Line 70:
  
 The root cause for most issues in PHP's current variable syntax are the semantics of the variable-variable syntax The root cause for most issues in PHP's current variable syntax are the semantics of the variable-variable syntax
-''%%$$foo['bar']%%''. Namely this expression is intepreted as ''%%${$foo['bar']}%%'' (lookup the variable with the name+''%%$$foo['bar']%%''. Namely this expression is interpreted as ''%%${$foo['bar']}%%'' (lookup the variable with the name
 ''%%$foo['bar']%%'') rather than ''%%${$foo}['bar']%%'' (take the ''%%'bar'%%'' offset of the ''%%$$foo%%'' variable). ''%%$foo['bar']%%'') rather than ''%%${$foo}['bar']%%'' (take the ''%%'bar'%%'' offset of the ''%%$$foo%%'' variable).
  
Line 76: Line 77:
  
 Normally variable accesses are interpreted from left to right. ''%%$foo['bar']->baz%%'' will first fetch a variable Normally variable accesses are interpreted from left to right. ''%%$foo['bar']->baz%%'' will first fetch a variable
-named ''%%$foo%%'', then will take the ''%%'baz%%''' offset of the result and finally access the ''%%baz%%'' property.+named ''%%$foo%%'', then will take the ''%%'bar%%''' offset of the result and finally access the ''%%baz%%'' property.
 The ''%%$$foo['baz']%%'' syntax goes against that basic principle. Rather than fetching ''%%$$foo%%'' and then taking The ''%%$$foo['baz']%%'' syntax goes against that basic principle. Rather than fetching ''%%$$foo%%'' and then taking
-its ''%%'baz'%%'' offset, it will first fetch ''%%$foo%%'', fetch its ''%%baz%%'' offset and then look up a variable+its ''%%'baz'%%'' offset, it will first fetch ''%%$foo%%'', fetch its ''%%'baz'%%'' offset and then look up a variable
 with the name of the result. with the name of the result.
  
-This combination of an indirect reference and an offset is the **only** case where interpretation is inverted. For+This combination of an indirect reference and an offset is the **only** case where the interpretation is inverted. For
 example the very similar ''%%$$foo->bar%%'' will be interpreted as ''%%${$foo}->bar%%'' and not as ''%%${$foo->bar}%%''. example the very similar ''%%$$foo->bar%%'' will be interpreted as ''%%${$foo}->bar%%'' and not as ''%%${$foo->bar}%%''.
 It follows normal left-to-right semantics. Similarly ''%%$$foo::$bar%%'' is also interpreted as ''%%${$foo}::$bar%%'' It follows normal left-to-right semantics. Similarly ''%%$$foo::$bar%%'' is also interpreted as ''%%${$foo}::$bar%%''
Line 92: Line 93:
 ''%%Foo::$bar[1][2][3]%%'' is interpreted as an access to the static property ''%%Foo::$bar%%'', followed by fetches of ''%%Foo::$bar[1][2][3]%%'' is interpreted as an access to the static property ''%%Foo::$bar%%'', followed by fetches of
 the 1, 2 and 3 offsets. On the other hand ''%%Foo::$bar[1][2][3]()%%'' (notice the parentheses at the end) has an the 1, 2 and 3 offsets. On the other hand ''%%Foo::$bar[1][2][3]()%%'' (notice the parentheses at the end) has an
-entirely different interpretationThis does not call the function stored at ''%%Foo::$bar[1][2][3]%%''. Instead it+entirely different interpretationThis does not call the function stored at ''%%Foo::$bar[1][2][3]%%''. Instead it
 calls the static method of class ''%%Foo%%'' with name ''%%$bar[1][2][3]%%''. calls the static method of class ''%%Foo%%'' with name ''%%$bar[1][2][3]%%''.
  
 The last issue implies that PHP's variable syntax is non-local. It is not possible to parse a PHP variable access with The last issue implies that PHP's variable syntax is non-local. It is not possible to parse a PHP variable access with
-a fixed finite lookahead (most parsers have only one token lookahead), without transplanting the generated syntax tree +a fixed finite lookahead, without transplanting the generated syntax tree or instructions after the fact.
-or instructions after the fact.+
  
 ==== Impact on parser definition ==== ==== Impact on parser definition ====
  
-In addition to the problems described above the semantics for indirect references also has far-reaching consequences on +In addition to the problems described above the semantics for indirect references also have far-reaching consequences on 
-how the variable syntax is defined in our parser. In the following I will outline the kind of issue it causes, for+how the variable syntax is defined in our parser. In the following I will outline the kind of issues it causes, for
 readers not familiar with parser construction: readers not familiar with parser construction:
  
Line 141: Line 141:
 </code> </code>
  
-However, this is not possible because it makes the grammer ambiguous. When the parser encounters ''%%$$foo['bar']%%'' it+However, this is not possible because it makes the grammar ambiguous. When the parser encounters ''%%$$foo['bar']%%'' it
 could either interpret it using the ''%%'$' reference_variable%%'' rule (i.e. ''%%${$foo['bar']}%%'' semantics) or using could either interpret it using the ''%%'$' reference_variable%%'' rule (i.e. ''%%${$foo['bar']}%%'' semantics) or using
 the ''%%variable '[' expr ']'%%'' rule (i.e. ''%%${$foo}['bar']%%'' semantics). This kind of issue is called a the ''%%variable '[' expr ']'%%'' rule (i.e. ''%%${$foo}['bar']%%'' semantics). This kind of issue is called a
Line 158: Line 158:
  
 Because of the implementational hurdles described in the previous section, we do not support all combinations of Because of the implementational hurdles described in the previous section, we do not support all combinations of
-dereferencing operations to an arbitrary death. While PHP 5.4 fixed the most glaring issue (support for+dereferencing operations to an arbitrary depth. While PHP 5.4 fixed the most glaring issue (support for
 ''%%$foo->bar()['baz']%%''), other problems still exist. ''%%$foo->bar()['baz']%%''), other problems still exist.
  
Line 166: Line 166:
 syntax implemented in PHP 5.5 allows you to write ''%%[$obj1, $obj2][0]%%'', but ''%%[$obj1, $obj2][0]->prop%%'' is not syntax implemented in PHP 5.5 allows you to write ''%%[$obj1, $obj2][0]%%'', but ''%%[$obj1, $obj2][0]->prop%%'' is not
 possible. Yet another example is that the alternative array syntax ''%%$str{0}%%'' is not supported on function calls, possible. Yet another example is that the alternative array syntax ''%%$str{0}%%'' is not supported on function calls,
-i.e. ''%%getStr(){0}%%'' is not valid. I think the pattern should be clear by now.+i.e. ''%%getStr(){0}%%'' is not valid.
  
 The second class of issues is that some nesting types aren't supported altogether. For example ''%%::%%'' only accepts The second class of issues is that some nesting types aren't supported altogether. For example ''%%::%%'' only accepts
Line 182: Line 182:
 ==== Miscellaneous other issues ==== ==== Miscellaneous other issues ====
  
-=== Behavior in write/isset context ===+=== Behavior in non-read context ===
  
 The new ''%%(new Foo)['bar']%%'' and ''%%[...]['bar']%%'' syntaxes introduced in PHP 5.4 and PHP 5.5 were implemented as The new ''%%(new Foo)['bar']%%'' and ''%%[...]['bar']%%'' syntaxes introduced in PHP 5.4 and PHP 5.5 were implemented as
-"non-variable expressions"Primarily this means that it is not possible to assign to them under any circumstances, even +"non-variable expressions"This means that they are always compiled in "read context", even when they are used in a different context.
-if it would be technically possible. E.g. there is nothing inherently problematic with writing +
-''%%(new Foo)['bar'] = 42%%'' (it's no different than writing ''%%foo()['bar'] = 42%%'', which is possible). However +
-this is not allowed.+
  
-Furthermore this causes inconsistent behavior in ''%%empty()%%'': The expression ''%%empty(['bar' => 42]['bar'])%%'' +For example ''%%empty(['foo' => 42]['bar'])%%'' will generate an "Undefined index" notice, even though ''%%empty()%%'' usually suppresses such warnings. The reason behind this is that proper behavior in isset/empty requires compilation using ''BP_VAR_IS'' rather than ''BP_VAR_R''
-will generate an "Undefined index" notice, even though ''%%empty()%%'' normally suppresses these.+ 
 +This also means that assignments to dereferences of parenthesis-expressions are never allowed, even when they would be technically possible. E.g. it's not possible to write ''%%(new Foo)['bar'] = 42%%''. Whether this would be particularly useful (the assignment would only be visible through ''offsetSet'') is another question, but it's not much different than writing something like ''%%foo()['bar'] = 42%%'', which is allowed.
  
 === Superfluous CVs on static property access === === Superfluous CVs on static property access ===
Line 198: Line 196:
 ''%%$bar%%'', even though it is not necessary and never used. This is once again related to the way static member access ''%%$bar%%'', even though it is not necessary and never used. This is once again related to the way static member access
 needs to be implemented to support our weird indirect reference semantics. needs to be implemented to support our weird indirect reference semantics.
- 
-=== TODO === 
  
 ===== Proposal ===== ===== Proposal =====
Line 274: Line 270:
  
 <code> <code>
-$$foo['bar']['baz'  interpreted as ($$foo)['bar']['baz'+$$foo['bar']['baz'  interpreted as   ($$foo)['bar']['baz'
-Foo::$bar['baz']()    interpreted as (Foo::$bar)['baz']() +$foo->$bar['baz'    interpreted as   ($foo->$bar)['baz'
-$foo->$bar['baz']()   interpreted as ($foo->$bar)['baz']()+$foo->$bar['baz']()   interpreted as   ($foo->$bar)['baz']() 
 +Foo::$bar['baz']()    interpreted as   (Foo::$bar)['baz']()
 </code> </code>
  
-This change is **backwards incompatible** (with low practical impact), which is the reason why this RFC targets PHP 6.+This change is **backwards incompatible** (with low practical impact), which is the reason why this RFC targets PHP 7.
 However it is always possible to recreate the old behavior by explicitly using braces: However it is always possible to recreate the old behavior by explicitly using braces:
  
-<code>+<code php>
 ${$foo['bar']['baz']} ${$foo['bar']['baz']}
 Foo::{$bar['baz']}() Foo::{$bar['baz']}()
Line 288: Line 285:
 </code> </code>
  
-This syntax will have guaranteed same behavior in both PHP 5 and PHP 6.+This syntax will have guaranteed same behavior in both PHP 5 and PHP 7.
  
 ==== Newly added and generalized syntax ==== ==== Newly added and generalized syntax ====
Line 323: Line 320:
 ==== Class name variable for new expression ==== ==== Class name variable for new expression ====
  
-It has always been possible to create classes using a dynamic class by writing ''%%new $className()%%'' or similar.+It has always been possible to create classes using a dynamically specified class name by writing ''%%new $className()%%'' or similar.
 However the supported variables are more limited in this case: They may not include calls anywhere, as this would cause However the supported variables are more limited in this case: They may not include calls anywhere, as this would cause
 ambiguity with the constructor parameter list. New variables are now defined as follows: ambiguity with the constructor parameter list. New variables are now defined as follows:
Line 338: Line 335:
 </code> </code>
  
-This matches the previously allowed variable expressions, with the minor extension of allowing chaning of ''%%::%%''.+This matches the previously allowed variable expressions, with the minor extension of allowing chaining of ''%%::%%''.
 For example ''%%new $foo['bar']::$baz%%'' would now be possible. For example ''%%new $foo['bar']::$baz%%'' would now be possible.
      
Line 347: Line 344:
 breaks. breaks.
  
-The former is a change in the behavior of currently existing syntax: Expressions like ''%%$foo->$bar['baz']()%%'' will +The former is a change in the behavior of currently existing syntax. Examples: 
-nowbe interpreted as ''%%($foo->$bar['baz'])()%%'' rather than ''%%$foo->{$bar['baz']}()%%''.+ 
 +<code php> 
 +                        // old meaning            // new meaning 
 +$$foo['bar']['baz'    ${$foo['bar']['baz']}     ($$foo)['bar']['baz'
 +$foo->$bar['baz'      $foo->{$bar['baz']}       ($foo->$bar)['baz'] 
 +$foo->$bar['baz']()     $foo->{$bar['baz']}(    ($foo->$bar)['baz']() 
 +Foo::$bar['baz']()      Foo::{$bar['baz']}()      (Foo::$bar)['baz']() 
 +</code>
  
 An analysis of the Zend Framework and Symfony projects (including standard dependencies) showed that only a single An analysis of the Zend Framework and Symfony projects (including standard dependencies) showed that only a single
-occurance of ''%%$loader[0]::$loader[1]($className)%%'' in the Doctrine class loader will be affected by this change. +occurrence of ''%%$loader[0]::$loader[1]($className)%%'' in the Doctrine class loader will be affected by this change. 
-This occurance must be replaced with ''%%$loader[0]::{$loader[1]}($className)%%'' to achieve compatibility with both +This occurrence must be replaced with ''%%$loader[0]::{$loader[1]}($className)%%'' to achieve compatibility with both 
-PHP 5 and PHP 6.+PHP 5 and PHP 7.
  
 The latter change turns currently valid syntax into a parse error. Expressions like ''%%global $$foo->bar%%'' are no The latter change turns currently valid syntax into a parse error. Expressions like ''%%global $$foo->bar%%'' are no
 longer valid and ''%%global ${$foo->bar}%%'' must be used instead. longer valid and ''%%global ${$foo->bar}%%'' must be used instead.
  
-As these changes only apply to some very rarely used syntax, the breakage seems acceptable for PHP 6.+As these changes only apply to some very rarely used syntax, the breakage seems acceptable for PHP 7.
  
 ===== Open issues ===== ===== Open issues =====
  
 The current patch introduces a new "write context" issue. Namely ''%%($foo)['bar'] = 'baz'%%'' will not behave this same The current patch introduces a new "write context" issue. Namely ''%%($foo)['bar'] = 'baz'%%'' will not behave this same
-was as ''%%$foo['bar'] = 'baz'%%''. In the former case an undefined variable notice will be thrownif ''%%$foo%%'' does+was as ''%%$foo['bar'] = 'baz'%%''. In the former case an undefined variable notice will be thrown if ''%%$foo%%'' does
 not exist, whereas the latter does not throw a notice. not exist, whereas the latter does not throw a notice.
  
Line 380: Line 384:
 The main changes are limited to the language parser and compiler. Furthermore some opcode handlers had to be modified The main changes are limited to the language parser and compiler. Furthermore some opcode handlers had to be modified
 to support ''CONST'' and ''TMP'' operands. to support ''CONST'' and ''TMP'' operands.
 +
 +===== Vote =====
 +
 +As this is a language change, a 2/3 majority is required for acceptance. The vote started on 2014-07-07 and ended on 2014-07-14.
 +
 +<doodle title="Implement Uniform Variable Syntax in PHP 6?" auth="nikic" voteType="single" closed="true">
 +   * Yes
 +   * No
 +</doodle>
 +
rfc/uniform_variable_syntax.1402070271.txt.gz · Last modified: 2017/09/22 13:28 (external edit)