Home > Article > Backend Development > PHP 7.0 upgrade notes, php7.0 upgrade notes_PHP tutorial

PHP 7.0 upgrade notes, php7.0 upgrade notes_PHP tutorial

WBOYOriginal: 2016-07-13 09:46:06809browse

PHP 7.0 upgrade notes, php7.0 upgrade notes

PHP 7.0.0 beta1 has been released, which not only brings eye-catching performance improvements, but also brings Many language feature changes. The following is translated by LCTT from the official upgrade notes. Although it is not an official release version yet, it is presumably not much different from the officially released features. (This article will continue to be tracked and updated)

1. Backward-incompatible changes

Language changes

Changes in variable handling

Indirect variable, property and method references are now interpreted with left-to-right semantics. Some examples:
1. $$foo['bar']['baz'] // 解释做 ($$foo)['bar']['baz'] 
2. $foo->$bar['baz'] // 解释做 ($foo->$bar)['baz']
3. $foo->$bar['baz']() // 解释做 ($foo->$bar)['baz']()
4. Foo::$bar['baz']() // 解释做 (Foo::$bar)['baz']()
To restore the previous behavior, explicitly add braces:
1. ${$foo['bar']['baz']}
2. $foo->{$bar['baz']}
3. $foo->{$bar['baz']}()
4. Foo::{$bar['baz']}()
Global keywords now only accept simple variables. Like before
1. global $$foo->bar;
Now the following writing method is required:
1. global ${$foo->bar};
Placing parentheses around variables or function calls no longer has any effect. For example, in the following code, the function call result is passed to a function by reference
1. function getArray() { return [1, 2, 3]; }
3. $last = array_pop(getArray());
4. // Strict Standards: 只有变量可以用引用方式传递
5. $last = array_pop((getArray()));
6. // Strict Standards: 只有变量可以用引用方式传递
Now throws a strict standard error whether or not parentheses are used. Previously there was no prompt in the second calling method.
Array elements or object properties are automatically created in reference order and the resulting order will now be different. For example:
1. $array = [];
2. $array["a"] =& $array["b"];
3. $array["b"] = 1;
4. var_dump($array);
Now the result is ["a" => 1, "b" => 1], while the previous result was ["b" => 1, "a" => 1].

Related RFCs:

https://wiki.php.net/rfc/uniform_variable_syntax
https://wiki.php.net/rfc/abstract_syntax_tree

Changes in list()

list() no longer assigns values in reverse order, for example:
1. list($array[], $array[], $array[]) = [1, 2, 3];
2. var_dump($array);
Now the result is $array == [1, 2, 3] instead of [3, 2, 1]. Note that only the assignment order has changed, but the assignment is still the same (LCTT translation annotation: that is, the previous list() behavior was to assign values one by one starting from the following variables, so that the above usage will produce [3,2, 1] This is the result. For example, common usage like the following
1. list($a, $b, $c) = [1, 2, 3];
2. // $a = 1; $b = 2; $c = 3;
Still maintains current behavior.
Assignment to an empty list() is no longer allowed. The following are all invalid:
1. list() = $a;
2. list(,,) = $a;
3. list($x, list(), $y) = $a;
list() no longer supports splitting strings (it used to be supported only in certain circumstances). The following code:
1. $string = "xy";
2. list($x, $y) = $string;
The result now is: $x == null and $y == null (without prompt), whereas before the result was: $x == "x" and $y == "y" . Additionally, list() can now always handle objects that implement ArrayAccess, for example:
1. list($a, $b) = (object) new ArrayObject([0, 1]);
The result now is: $a == 0 and $b == 1. Previously $a and $b were both null.

Related RFC:

https://wiki.php.net/rfc/abstract_syntax_tree#changes_to_list
https://wiki.php.net/rfc/fix_list_behavior_inconsistency

Changes of foreach

foreach() iteration no longer affects the internal pointer of the array, and the array pointer can be accessed through current()/next() and other series of functions. For example:
1. $array = [0, 1, 2];
2. foreach ($array as &$val) {
3.  var_dump(current($array));
4. }
will now point to the value int(0) three times. Previous output was int(1), int(2), and bool(false).
When iterating an array by value, foreach always operates on a copy of the array, and any operations on the array during iteration will not affect the iteration behavior. For example:
1. $array = [0, 1, 2];
2. $ref =& $array; // Necessary to trigger the old behavior
3. foreach ($array as $val) {
4.  var_dump($val);
5.  unset($array[1]);
6. }
All three elements (0 1 2) will now be printed, whereas previously the second element 1 would be skipped (0 2).
When iterating over an array by reference, modifications to the array will continue to affect the iteration. However, PHP now maintains better positioning within arrays when using numbers as keys. For example, adding array elements during by-reference iteration:
1. $array = [0];
2. foreach ($array as &$val) {
3.  var_dump($val);
4.  $array[1] = 1;
5. }
Iteration now correctly adds elements. The output of the above code is "int(0) int(1)", whereas before it was just "int(0)".
Iteration by value or by reference over a normal (non-traversable) object behaves like iteration by reference over an array. This is in line with previous behavior, except for improvements to more precise location management as mentioned in the previous point.
The behavior of iteration over traversable objects remains unchanged.

Related RFC: https://wiki.php.net/rfc/php7_foreach

Changes in parameter handling

Cannot define two function parameters with the same name. For example, the following method will trigger a compile-time error:
1. public function foo($a, $b, $unused, $unused) {
2.  // ...
3. }
The above code should be modified to use different parameter names, such as:
1. public function foo($a, $b, $unused1, $unused2) {
2.  // ...
3. }
The func_get_arg() and func_get_args() functions no longer return the original value passed to the argument, but instead return its current value (perhaps modified). For example:
1. function foo($x) {
2.  $x ;
3.  var_dump(func_get_arg(0));
4. }
5. foo(1);
will print "2" instead of "1". The code should be changed to modify only after calling func_get_arg(s).
1. function foo($x) {
2.  var_dump(func_get_arg(0));
3.  $x ;
4. }
Or modification of parameters should be avoided:
1. function foo($x) {
2.  $newX = $x 1;
3.  var_dump(func_get_arg(0));
4. }
Similarly, the exception traceback no longer displays the original value passed to the function, but the modified value. For example:
1. function foo($x) {
2.  $x = 42;
3.  throw new Exception;
4. }
5. foo("string");
Now the stack trace is:
1. Stack trace:
2. #0 file.php(4): foo(42)
3. #1 {main}
Whereas it used to be:
1. Stack trace:
2. #0 file.php(4): foo('string')
3. #1 {main}
This does not affect the runtime behavior of your code, it is worth noting that it will be different when debugging.

The same limitation also affects debug_backtrace() and other functions that check function parameters.

Related RFC: https://wiki.php.net/phpng

Changes in integer handling

Invalid octal representation (containing numbers greater than 7) now produces a compilation error. For example, the following code no longer works:
1. $i = 0781; // 8 不是一个有效的八进制数字！
Previously, invalid numbers (and any numbers after the invalid number) were simply ignored. Previously the value of $i above was 7 because the last two digits were silently discarded.
Binary mirroring displacements with negative numbers now throws an arithmetic error:
1. var_dump(1 >> -1);
2. // ArithmeticError: 以负数进行位移
When the number of bits shifted to the left exceeds the width of the integer, the result is always 0.
1. var_dump(1 << 64); // int(0)
The results of the previous code depended on the CPU architecture used. For example, on x86 (including x86-64) the result is int(1) because its shift operand is in range.
Similarly, shifting to the right by more than the width of the integer always results in 0 or -1 (depending on the sign):
1. var_dump(1 >> 64); // int(0)
2. var_dump(-1 >> 64); // int(-1)

Related RFC: https://wiki.php.net/rfc/integer_semantics

Changes in string handling

Strings containing hexadecimal digits will no longer be treated as numbers, nor will they be treated specially. See the new behavior in the example:
1. var_dump("0x123" == "291"); // bool(false) (以前是 true)
2. var_dump(is_numeric("0x123")); // bool(false) (以前是 true)
3. var_dump("0xe" "0x1"); // int(0) (以前是 16)
5. var_dump(substr("foo", "0x1")); // string(3) "foo" (以前是 "oo")
6. // 注意：遇到了一个非正常格式的数字
filter_var() can be used to check whether a string contains hexadecimal digits, or whether the string can be converted to an integer:
1. $str = "0xffff";
2. $int = filter_var($str, FILTER_VALIDATE_INT, FILTER_FLAG_ALLOW_HEX);
3. if (false === $int) {
4.  throw new Exception("Invalid integer!");
5. }
6. var_dump($int); // int(65535)
Due to the addition of Unicode Codepoint Escape Syntax to double-quoted strings and HERE documents, "u{" with an invalid sequence now causes an error:
1. $str = "u{xyz}"; // 致命错误：无效的 UTF-8 码点转义序列
To avoid this, escape the leading backslash:
1. $str = "\u{xyz}"; // 正确
However, "u" not followed by { is not affected. The following code will not generate an error and works the same as the previous one:
1. $str = "u202e"; // 正确

Related RFC:

https://wiki.php.net/rfc/remove_hex_support_in_numeric_strings
https://wiki.php.net/rfc/unicode_escape

Changes in error handling

There are now two exception classes: Exception and Error . Both classes implement a new interface: Throwable. Type directives in exception handling code may need to be modified to handle this situation.
Some fatal and recoverable fatal errors now throw an Error instead. Since Error is a separate class from Exception, these exceptions will not be caught by existing try/catch blocks.

Recoverable fatal errors are converted into an exception, so they cannot be silently ignored in error handling. Type indication failures can no longer be ignored in some cases.
Parse errors now generate an Error extended ParseError . In addition to the previous return value/errorgetlast() based handling, error handling of eval() for some potentially invalid code should instead catch ParseError .
Constructors of inner classes always throw an exception on failure. Previously some constructors would return NULL or an unavailable object.
The error levels of some E_STRICT prompts have been changed.

Related RFC:

https://wiki.php.net/rfc/engine_exceptions_for_php7
https://wiki.php.net/rfc/throwable-interface
https://wiki.php.net/rfc/internal_constructor_behaviour
https://wiki.php.net/rfc/reclassify_e_strict

Other language changes

Static calling a non-static call with an incompatible $this context is no longer supported. In this case, $this is undefined, but calls to it are allowed with a deprecation hint. Example:
1. class A {
2. public function test() { var_dump($this); }
3. }
5. // 注意：没有从类 A 进行扩展
6. class B {
7. public function callNonStaticMethodOfA() { A::test(); }
8. }
10. (new B)->callNonStaticMethodOfA();
12. // 废弃：非静态方法 A::test() 不应该被静态调用
13. // 提示：未定义的变量 $this
14. NULL
Note that this only occurs on calls from incompatible contexts. If class B extends from class A, the call will be allowed without any prompts.
The following class names, interface names and special names (case sensitive) cannot be used:
1. bool
2. int
3. float
4. string
5. null
6. false
7. true
This is used in class/interface/trait declarations, class_alias() and use statements.

In addition, the following class names, interface names, and special names are reserved for future use, but will not throw an error when used:
1. resource
2. object
3. mixed
4. numeric
The
yield statement structure no longer requires parentheses when used in the context of an expression. It is now a right-associative operator with precedence between "print" and "=>". This can lead to different behavior in some cases, for example:
1. echo yield -1;
2. // 以前被解释如下
3. echo (yield) - 1;
4. // 现在被解释如下
5. echo yield (-1);
7. yield $foo or die;
8. // 以前被解释如下
9. yield ($foo or die);
10. // 现在被解释如下
11. (yield $foo) or die;
This situation can be solved by adding parentheses.
Removed ASP (<%) and script (