rfc:uniform_variable_syntax

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
rfc:uniform_variable_syntax [2014/06/06 14:15] nikicrfc:uniform_variable_syntax [2017/09/22 13:28] (current) – external edit 127.0.0.1
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
  
-===== Overview =====+===== Introduction =====
  
 This RFC proposes the introduction of an internally consistent and complete variable syntax. To achieve this goal the This RFC proposes the introduction of an internally consistent and complete variable syntax. To achieve this goal the
 semantics of some rarely used variable-variable constructions need to be changed. semantics of some rarely used variable-variable constructions need to be changed.
  
-TODO+Examples of expressions that were previously invalid, but will be valid with the uniform variable syntax: 
 + 
 +<code php> 
 +// support missing combinations of operations 
 +$foo()['bar']() 
 +[$obj1, $obj2][0]->prop 
 +getStr(){0} 
 + 
 +// support nested :: 
 +$foo['bar']::$baz 
 +$foo::$bar::$baz 
 +$foo->bar()::baz() 
 + 
 +// support nested () 
 +foo()() 
 +$foo->bar()() 
 +Foo::bar()() 
 +$foo()() 
 + 
 +// support operations on arbitrary (...) expressions 
 +(...)['foo'
 +(...)->foo 
 +(...)->foo() 
 +(...)::$foo 
 +(...)::foo() 
 +(...)() 
 + 
 +// two more practical examples for the last point 
 +(function() { ... })() 
 +($obj->closure)() 
 + 
 +// support all operations on dereferencable scalars (not very useful) 
 +"string"->toLower() 
 +[$obj, 'method']() 
 +'Foo'::$bar 
 +</code> 
 + 
 +Example of expressions those meaning changes: 
 + 
 +<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> 
 + 
 +Examples of statements which are no longer supported: 
 + 
 +<code php> 
 +global $$foo->bar; 
 +// instead use: 
 +global ${$foo->bar}; 
 +</code>
  
 ===== Issues with the current syntax ===== ===== Issues with the current syntax =====
Line 17: 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 24: 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 40: 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 89: 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 106: 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 114: 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 130: 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 146: 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 222: 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 236: 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 268: Line 317:
 For example the expression ''%%'foo'[0] = 'b'%%'' will result in a "Cannot use temporary expression in write context" For example the expression ''%%'foo'[0] = 'b'%%'' will result in a "Cannot use temporary expression in write context"
 compile error. For ''%%BP_VAR_FUNC_ARG%%'' fetches a runtime fatal error is thrown instead. compile error. For ''%%BP_VAR_FUNC_ARG%%'' fetches a runtime fatal error is thrown instead.
 +
 +==== Class name variable for new expression ====
 +
 +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
 +ambiguity with the constructor parameter list. New variables are now defined as follows:
 +
 +<code>
 +new_variable:
 +        simple_variable
 +    |   new_variable '[' dim_offset ']'
 +    |   new_variable '{' expr '}'
 +    |   new_variable T_OBJECT_OPERATOR member_name
 +    |   class_name T_PAAMAYIM_NEKUDOTAYIM simple_variable
 +    |   new_variable T_PAAMAYIM_NEKUDOTAYIM simple_variable
 +;
 +</code>
 +
 +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.
      
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
Line 275: 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 ===== 
 + 
 +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 thrown if ''%%$foo%%'' does 
 +not exist, whereas the latter does not throw a notice. 
 + 
 +The reason for this is that ''%%(...)%%'' is always interpreted as an expression, and not a variable. This means that 
 +the part in parentheses will always be compiled in "read context", even though write context is desired. 
 + 
 +This issue already exists currently, in a different context: The expression ''%%byRef(func())%%'' will throw a strict 
 +standards notice, if ''%%byRef()%%'' accepts the first argument by-reference, but ''%%func()%%'' does not return by 
 +reference. On the other hand ''%%byRef((func()))%%'' will throw no such notice, because ''%%(func())%%'' is recognized 
 +as an expression instead of a variable.
  
 ===== Patch ===== ===== Patch =====
  
-https://github.com/nikic/php-src/compare/nikic:phpng...uniformVariableSyntax+An implementation of this proposal against the phpng branch is available at https://github.com/php/php-src/pull/686. 
 + 
 +The main changes are limited to the language parser and compilerFurthermore some opcode handlers had to be modified 
 +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.1402064137.txt.gz · Last modified: 2017/09/22 13:28 (external edit)