From d1137a590971b25595a9888c07e2f9246ef04a8a Mon Sep 17 00:00:00 2001 From: wxy Date: Sat, 18 Jul 2015 17:31:08 +0800 Subject: [PATCH] =?UTF-8?q?=E7=BF=BB=E8=AF=91=20PHP=20=E5=8D=87=E7=BA=A7?= =?UTF-8?q?=E5=A4=87=E6=B3=A8?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- sources/tech/PHP 7 upgrading.md | 626 ++++++++++++++++++++++++++++++++ 1 file changed, 626 insertions(+) create mode 100644 sources/tech/PHP 7 upgrading.md diff --git a/sources/tech/PHP 7 upgrading.md b/sources/tech/PHP 7 upgrading.md new file mode 100644 index 0000000000..aa1530644d --- /dev/null +++ b/sources/tech/PHP 7 upgrading.md @@ -0,0 +1,626 @@ +PHP 7.0 升级备注 +=============== + +1. 向后不兼容的变化 +2. 新功能 +3. SAPI 模块中的变化 +4. 废弃的功能 +5. 变化的功能 +6. 新功能 +7. 新的类和接口 +8. 移除的扩展和 SAPI +9. 扩展的其它变化 +10. 新的全局常量 +11. INI 文件处理的变化 +12. Windows 支持 +13. 其它变化 + + +##1. 向后不兼容的变化 + +###语言变化 + +####变量处理的变化 + +* 间接变量、属性和方法引用现在以从左到右的语义进行解释。一些例子: + + $$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']}() + +* 全局关键字现在只接受简单变量。像以前的 + + global $$foo->bar; + + 现在要求如下写法: + + global ${$foo->bar}; + +* 变量或函数调用的前后加上括号不再有任何影响。例如下列代码,函数调用结果以引用的方式传给一个函数 + + function getArray() { return [1, 2, 3]; } + + $last = array_pop(getArray()); + // Strict Standards: 只有变量可以用引用方式传递 + $last = array_pop((getArray())); + // Strict Standards: 只有变量可以用引用方式传递 + + 现在无论是否使用括号,都会抛出一个严格标准错误。以前在第二种调用方式下不会有提示。 + +* 数组元素或对象属性自动安装引用顺序创建,现在的结果顺序将不同。例如: + + $array = []; + $array["a"] =& $array["b"]; + $array["b"] = 1; + var_dump($array); + + 现在结果是 ["a" => 1, "b" => 1],而以前的结果是 ["b" => 1, "a" => 1]。 + +相关的 RFC: +* https://wiki.php.net/rfc/uniform_variable_syntax +* https://wiki.php.net/rfc/abstract_syntax_tree + +####list() 的变化 + +* list() 不再以反序赋值,例如: + + list($array[], $array[], $array[]) = [1, 2, 3]; + var_dump($array); + + 现在结果是 $array == [1, 2, 3] ,而不是 [3, 2, 1]。注意仅赋值**顺序**变化了,而赋值仍然一致(LCTT 译注:即以前的 list()行为是从后面的变量开始逐一赋值,这样对与上述用法就会产生 [3,2,1] 这样的结果了。)。例如,类似如下的常规用法 + + list($a, $b, $c) = [1, 2, 3]; + // $a = 1; $b = 2; $c = 3; + + 仍然保持当前的行为。 + +* 不再允许对空的 list() 赋值。如下全是无效的: + + list() = $a; + list(,,) = $a; + list($x, list(), $y) = $a; + +* list() 不再支持对字符串的拆分(以前也只在某些情况下支持)。如下代码: + + $string = "xy"; + list($x, $y) = $string; + + 现在的结果是: $x == null 和 $y == null (没有提示),而以前的结果是: + $x == "x" 和 $y == "y" 。此外, list() 现在总是可以处理实现了 ArrayAccess 的对象,例如: + + list($a, $b) = (object) new ArrayObject([0, 1]); + + 现在的结果是: $a == 0 和 $b == 1。 以前 $a 和 $b 都是 null。 + +相关 RFC: +* https://wiki.php.net/rfc/abstract_syntax_tree#changes_to_list +* https://wiki.php.net/rfc/fix_list_behavior_inconsistency + +####foreach 的变化 + +* foreach() 迭代不再影响数组内部指针,数组指针可通过 current()/next() 等系列的函数访问。例如: + + $array = [0, 1, 2]; + foreach ($array as &$val) { + var_dump(current($array)); + } + + 现在将指向值 int(0) 三次。以前的输出是 int(1)、int(2) 和 bool(false)。 + +* 在对数组按值迭代时,foreach 总是在对数组副本进行操作,在迭代中任何对数组的操作都不会影响到迭代行为。例如: + + $array = [0, 1, 2]; + $ref =& $array; // Necessary to trigger the old behavior + foreach ($array as $val) { + var_dump($val); + unset($array[1]); + } + + 现在将打印出全部三个元素 (0 1 2),而以前第二个元素 1 会跳过 (0 2)。 + +* 在对数组按引用迭代时,对数组的修改将继续会影响到迭代。不过,现在 PHP 在使用数字作为键时可以更好的维护数组内的位置。例如,在按引用迭代过程中添加数组元素: + + $array = [0]; + foreach ($array as &$val) { + var_dump($val); + $array[1] = 1; + } + + 现在迭代会正确的添加了元素。如上代码输出是 "int(0) int(1)",而以前只是 "int(0)"。 + +* 对普通(不可遍历的)对象按值或按引用迭代的行为类似于对数组进行按引用迭代。这符合以前的行为,除了如上一点所述的更精确的位置管理的改进。 + +* 对可遍历对象的迭代行为保持不变。 + +相关 RFC: https://wiki.php.net/rfc/php7_foreach + +####参数处理的变化 + +* 不能定义两个同名的函数参数。例如,下面的方法将会触发编译时错误: + + 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) + +* 由于给双引号字符串和 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 。除了以前的基于返回值 / error_get_last() 的处理,对某些可能无效的代码的 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(); + + // 废弃:非静态方法 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 (\