Home > Backend Development > PHP Tutorial > PHP7.0 version notes, php7.0 notes_PHP tutorial

PHP7.0 version notes, php7.0 notes_PHP tutorial

WBOY
Release: 2016-07-13 09:45:52
Original
762 people have browsed it

Notes on PHP7.0 version, Notes on php7.0

The new version of PHP7.0 not only greatly improves performance but also changes a lot in terms of language features. Please see below for detailed explanation :


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:

$$foo['bar']['baz'] // 解释做 ($$foo)['bar']['baz']
$foo->$bar['baz'] // 解释做 ($foo->$bar)['baz']
$foo->$bar['baz']() // 解释做 ($foo->$bar)['baz']()
Foo::$bar['baz']() // 解释做 (Foo::$bar)['baz']()
Copy after login


To restore the previous behavior, explicitly add braces:

${$foo['bar']['baz']}
$foo->{$bar['baz']}
$foo->{$bar['baz']}()
Foo::{$bar['baz']}()
Copy after login

Global keywords now only accept simple variables. Like before

Copy code The code is as follows:
global $$foo->bar;

Now the following writing method is required:

Copy code The code is as follows:
global ${$foo->bar};

Placing parentheses around a variable or function call no longer has any effect. For example, in the following code, the function call result is passed to a function by reference

function getArray() { return [1, 2, 3]; }
$last = array_pop(getArray());
// Strict Standards: 只有变量可以用引用方式传递
$last = array_pop((getArray()));
Copy after login


// Strict Standards: Only variables can be passed by reference
Now a strict standard error is thrown regardless of whether 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:

$array = [];
$array["a"] =& $array["b"];
$array["b"] = 1;
var_dump($array);
现在结果是 ["a" => 1, "b" => 1],而以前的结果是 ["b" => 1, "a" => 1]

Copy after login

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:

Copy code The code is as follows:
list($array[], $array[], $array[]) = [1, 2, 3];
var_dump($array);

Now the result is $array == [1, 2, 3] instead of [3, 2, 1]. Note that only the order of assignment has changed, but the assignment is still the same (LCTT translation: 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 a result like [3,2,1] .). For example, common usage like the following

Copy code The code is as follows:
list($a, $b, $c) = [1, 2, 3];
// $a = 1; $b = 2; $c = 3;

Current behavior is still maintained.

Assignment to an empty list() is no longer allowed. The following are all invalid:

list() = $a;
list(,,) = $a;
list($x, list(), $y) = $a;
list() 不再支持对字符串的拆分(以前也只在某些情况下支持)
Copy after login

The following code:

Copy code The code is as follows:
$string = "xy";
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:

Copy code The code is as follows:
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 to foreach
foreach() iteration no longer affects the internal array pointer, which can be accessed through current()/next() and other series of functions. For example:

Copy code The code is as follows:
$array = [0, 1, 2];
foreach ($array as &$val) {
var_dump(current($array));
}

It 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:

Copy code The code is as follows:
$array = [0, 1, 2];
$ref =& $array; // Necessary to trigger the old behavior
foreach ($array as $val) {
var_dump($val);
unset($array[1]);
}

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:

Copy code The code is as follows:
$array = [0];
foreach ($array as &$val) {
var_dump($val);
$array[1] = 1;
}

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
Two function parameters with the same name cannot be defined. For example, the following method will trigger a compile-time error:

复制代码 代码如下:
public function foo($a, $b, $unused, $unused) {
// ...
}

如上的代码应该修改使用不同的参数名,如:

复制代码 代码如下:
public function foo($a, $b, $unused1, $unused2) {
// ...
}

func_get_arg() 和 func_get_args() 函数不再返回传递给参数的原始值,而是返回其当前值(也许会被修改)。例如:

复制代码 代码如下:
function foo($x) {
$x++;
var_dump(func_get_arg(0));
}

foo(1);
将会打印 "2" 而不是 "1"。代码应该改成仅在调用 func_get_arg(s) 后进行修改操作。

复制代码 代码如下:
function foo($x) {
var_dump(func_get_arg(0));
$x++;
}

或者应该避免修改参数:

复制代码 代码如下:
function foo($x) {
$newX = $x + 1;
var_dump(func_get_arg(0));
}

类似的,异常回溯也不再显示传递给函数的原始值,而是修改后的值。例如:

复制代码 代码如下:
function foo($x) {
$x = 42;
throw new Exception;
}

foo("string");
现在堆栈跟踪的结果是:

复制代码 代码如下:
Stack trace:
#0 file.php(4): foo(42)
#1 {main}

而以前是:

复制代码 代码如下:
Stack trace:
#0 file.php(4): foo('string')
#1 {main}

这并不会影响到你的代码的运行时行为,值得注意的是在调试时会有所不同。

同样的限制也会影响到 debug_backtrace() 及其它检查函数参数的函数。

相关 RFC: https://wiki.php.net/phpng

整数处理的变化
无效的八进制表示(包含大于7的数字)现在会产生编译错误。例如,下列代码不再有效:

$i = 0781; // 8 不是一个有效的八进制数字!
以前,无效的数字(以及无效数字后的任何数字)会简单的忽略。以前如上 $i 的值是 7,因为后两位数字会被悄悄丢弃。

二进制以负数镜像位移现在会抛出一个算术错误:

复制代码 代码如下:
var_dump(1 >> -1);

// ArithmeticError: 以负数进行位移
向左位移的位数超出了整型宽度时,结果总是 0。

复制代码 代码如下:
var_dump(1 << 64); // int(0)

以前上述代码的结果依赖于所用的 CPU 架构。例如,在 x86(包括 x86-64) 上结果是 int(1),因为其位移操作数在范围内。

类似的,向右位移的位数超出了整型宽度时,其结果总是 0 或 -1 (依赖于符号):

复制代码 代码如下:
var_dump(1 >> 64); // int(0)
var_dump(-1 >> 64); // int(-1)

相关 RFC: https://wiki.php.net/rfc/integer_semantics

字符串处理的变化
包含十六进制数字的字符串不会再被当做数字,也不会被特殊处理。参见例子中的新行为:

复制代码 代码如下:
var_dump("0x123" == "291"); // bool(false) (以前是 true)
var_dump(is_numeric("0x123")); // bool(false) (以前是 true)
var_dump("0xe" + "0x1"); // int(0) (以前是 16)
var_dump(substr("foo", "0x1")); // string(3) "foo" (以前是 "oo")

// 注意:遇到了一个非正常格式的数字
filter_var() 可以用来检查一个字符串是否包含了十六进制数字,或这个字符串是否能转换为整数:

$str = "0xffff";
$int = filter_var($str, FILTER_VALIDATE_INT, FILTER_FLAG_ALLOW_HEX);
if (false === $int) {
throw new Exception("Invalid integer!");
}
var_dump($int); // int(65535)
Copy after login


由于给双引号字符串和 HERE 文档增加了 Unicode 码点转义格式(Unicode Codepoint Escape Syntax), 所以带有无效序列的 "\u{" 现在会造成错误:

$str = "\u{xyz}"; // 致命错误:无效的 UTF-8 码点转义序列
要避免这种情况,需要转义开头的反斜杠:

$str = "\\u{xyz}"; // 正确
不过,不跟随 { 的 "\u" 不受影响。如下代码不会生成错误,和前面的一样工作:

$str = "\u202e"; // 正确
相关 RFC:

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

错误处理的变化
现在有两个异常类: Exception 和 Error 。这两个类都实现了一个新接口: Throwable 。在异常处理代码中的类型指示也许需要修改来处理这种情况。

一些致命错误和可恢复的致命错误现在改为抛出一个 Error 。由于 Error 是一个独立于 Exception 的类,这些异常不会被已有的 try/catch 块捕获。

可恢复的致命错误被转换为一个异常,所以它们不能在错误处理里面悄悄的忽略。部分情况下,类型指示失败不再能忽略。

解析错误现在会生成一个 Error 扩展的 ParseError 。除了以前的基于返回值 / errorgetlast() 的处理,对某些可能无效的代码的 eval() 的错误处理应该改为捕获 ParseError 。

内部类的构造函数在失败时总是会抛出一个异常。以前一些构造函数会返回 NULL 或一个不可用的对象。

一些 E_STRICT 提示的错误级别改变了。

相关 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

其它的语言变化
静态调用一个不兼容的 $this 上下文的非静态调用的做法不再支持。这种情况下,$this 是没有定义的,但是对它的调用是允许的,并带有一个废弃提示。例子:

class A {
public function test() { var_dump($this); }
}
// 注意:没有从类 A 进行扩展
class B {
public function callNonStaticMethodOfA() { A::test(); }
}
(new B)->callNonStaticMethodOfA();
Copy after login

// 废弃:非静态方法 A::test() 不应该被静态调用
// 提示:未定义的变量 $this
NULL
注意,这仅出现在来自不兼容上下文的调用上。如果类 B 扩展自类 A ,调用会被允许,没有任何提示。

不能使用下列类名、接口名和特殊名(大小写敏感):

bool
int
float
string
null
false
true
这用于 class/interface/trait 声明、 class_alias() 和 use 语句中。

此外,下列类名、接口名和特殊名保留做将来使用,但是使用时尚不会抛出错误:

resource
object
mixed
numeric
yield 语句结构当用在一个表达式上下文时,不再要求括号。它现在是一个优先级在 “print” 和 “=>” 之间的右结合操作符。在某些情况下这会导致不同的行为,例如:

echo yield -1;
// 以前被解释如下
echo (yield) - 1;
// 现在被解释如下
echo yield (-1);
yield $foo or die;
// 以前被解释如下
yield ($foo or die);
// 现在被解释如下
(yield $foo) or die;
这种情况可以通过增加括号来解决。

移除了 ASP (<%) 和 script (

Popular Tutorials
More>
Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template