ホームページ > 記事 > バックエンド開発 > PHP 7.0 アップグレード試験の準備

PHP 7.0 アップグレード試験の準備

WBOYオリジナル: 2016-06-13 12:23:22756ブラウズ

PHP 7.0 アップグレードに関するメモ

PHP 7.0.0 ベータ 1 がリリースされました。これは、目を引くパフォーマンスの向上をもたらしただけでなく、言語機能にも多くの変更をもたらしました。以下は公式アップグレードノートから LCTT によって翻訳されたものですが、まだ正式リリース版ではありませんが、おそらく正式にリリースされた機能と大きな違いはありません。 (この記事は引き続き更新を追跡します)

1. 下位互換性のない変更

言語の変更

変数処理の変更

間接的な変数、プロパティ、およびメソッド参照が、左から右のセマンティクスで解釈されるようになりました。例:
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']()
以前の動作を復元するには、明示的に中かっこを追加する必要があります:
1. ${$foo['bar']['baz']}
2. $foo->{$bar['baz']}
3. $foo->{$bar['baz']}()
4. Foo::{$bar['baz']}()
グローバルキーワードは単純な変数のみを受け入れるようになりました。以前の
1. global $$foo->bar;
と同様に、
1. global ${$foo->bar};
変数または関数呼び出しを括弧で囲んでも効果がなくなりました。たとえば、次のコードでは、関数呼び出しの結果が参照によって関数に渡されます
1. function getArray() { return [1, 2, 3]; }
3. $last = array_pop(getArray());
4. // Strict Standards: 只有变量可以用引用方式传递
5. $last = array_pop((getArray()));
6. // Strict Standards: 只有变量可以用引用方式传递
括弧が使用されているかどうかに関係なく、厳密な標準エラーをスローするようになりました。以前は、2 番目の呼び出しメソッドにはプロンプトが表示されませんでした。
配列要素またはオブジェクトのプロパティは、作成時に参照順序で自動的にインストールされますが、結果の順序は異なります。例:
1. $array = [];
2. $array["a"] =& $array["b"];
3. $array["b"] = 1;
4. var_dump($array);
現在の結果は ["a" => 1, "b" => 1] ですが、以前の結果は ["b" => 1, "a" => 1] でした。

関連 RFC:

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

list() の変更

list() は値を逆の順序で割り当てなくなりました。例:
1. list($array[], $array[], $array[]) = [1, 2, 3];
2. var_dump($array);
今度は、結果は $array == [1, 2, 3] ではなく[3、21]。代入順序のみが変更されていますが、代入は同じであることに注意してください (LCTT 変換アノテーション: つまり、以前の list() の動作は、次の変数から開始して 1 つずつ値を代入していました) , 上記の使用法により [3,2, 1] が生成されるようになります。これが結果です。たとえば、
1. list($a, $b, $c) = [1, 2, 3];
2. // $a = 1; $b = 2; $c = 3;
などの通常の使用では、現在の動作が維持されます。
空の list() への代入は許可されなくなりました。以下はすべて無効です:
1. list() = $a;
2. list(,,) = $a;
3. list($x, list(), $y) = $a;
list() は、次のペアをサポートしなくなりました。文字列の分割 (以前は特定の状況でのみサポートされていました)。次のコード:
1. $string = "xy";
2. list($x, $y) = $string;
結果は次のようになります: $x == null および $y == null (プロンプトなし)、以前の結果は $x == "x" および $y == "y" でした。さらに、list() は常に ArrayAccess を実装するオブジェクトを処理できるようになりました。例:
1. 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() およびその他の一連の関数を通じてアクセスできます。例:
1. $array = [0, 1, 2];
2. foreach ($array as &$val) {
3.  var_dump(current($array));
4. }
値 int(0) を 3 回指すようになります。以前の出力は int(1)、int(2)、および bool(false) でした。
配列を値で反復する場合、foreach は常に配列のコピーを操作し、反復中の配列に対する操作は反復動作に影響しません。例:
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. }
は 3 つの要素すべて (0 1 2) を出力しますが、以前は 2 番目の要素 1 がスキップされていました (0 2)。
配列を参照によって反復する場合、配列への変更は引き続き反復に影響します。ただし、PHP では、数値をキーとして使用する場合に、配列内での位置をより適切に維持できるようになりました。たとえば、参照による反復中に配列要素を追加する場合:
1. $array = [0];
2. foreach ($array as &$val) {
3.  var_dump($val);
4.  $array[1] = 1;
5. }
反復により要素が正しく追加されるようになりました。上記のコードの出力は「int(0) int(1)」ですが、以前は単に「int(0)」でした。
通常の (走査不可能な) オブジェクトに対する値による反復または参照による反復は、配列に対する参照による反復と同様に動作します。これは、前の点で述べたより正確な位置管理の改善を除いて、以前の動作と一致しています。
走査可能なオブジェクトに対する反復動作は変更されません。

関連 RFC: https://wiki.php.net/rfc/php7_foreach

パラメータ処理の変更

同じ名前の 2 つの関数パラメータを定義することはできません。たとえば、次のメソッドはコンパイル時エラーをトリガーします:
1. public function foo($a, $b, $unused, $unused) {
2.  // ...
3. }
上記のコードは、次のような別のパラメーター名を使用するように変更する必要があります。
1. public function foo($a, $b, $unused1, $unused2) {
2.  // ...
3. }
func_get_arg() 関数と func_get_args() 関数は、引数に渡された元の値を返さず、代わりに現在の値 (おそらく変更された) を返すようになりました。例:
1. function foo($x) {
2.  $x ;
3.  var_dump(func_get_arg(0));
4. }
5. foo(1);
は「1」の代わりに「2」を出力します。コードは func_get_arg(s) を呼び出した後にのみ変更するように変更する必要があります。それともパラメータの変更は避けるべきでしょうか:
1. function foo($x) {
2.  var_dump(func_get_arg(0));
3.  $x ;
4. }
1. function foo($x) {
2.  $newX = $x 1;
3.  var_dump(func_get_arg(0));
4. }
1. スタックトレースの結果は次のようになります: function foo($x) {
2.  $x = 42;
3.  throw new Exception;
4. }
5. foo("string");以前は:
1. Stack trace:
2. #0 file.php(4): foo(42)
3. #1 {main}これは同じではありません。コードの実行時の動作には影響しません。デバッグ時に違いが生じることに注意してください。
同じ制限は、debug_backtrace() および関数パラメーターをチェックするその他の関数にも影響します。
1. 関連 RFC: https://wiki.php.net/phpngStack trace:
2. #0 file.php(4): foo('string')整数処理の変更
3. #1 {main}

以前は、無効な数字 (および無効な数字の後の数字) は単純に無視されていました。以前は、最後の 2 桁が黙って破棄されていたため、上記の $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

文字列処理の変更

16 進数を含む文字列は数値として扱われなくなり、特別に扱われなくなります。例の新しい動作を参照してください:
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() を使用して、文字列に 16 進数が含まれているかどうか、または文字列が整数に変換できるかどうかを確認できます。 🎜>
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)
二重引用符で囲まれた文字列と HERE ドキュメントに Unicode コードポイントエスケープ構文が追加されたため、無効なシーケンス u{" を含む "" によりエラーが発生するようになりました。
1. $str = "u{xyz}"; // 致命错误：无效的 UTF-8 码点转义序列
これを回避するには、先頭のバックスラッシュをエスケープする必要があります:
1. $str = "\u{xyz}"; // 正确
ただし、{ の後ろにない「u」は影響を受けません。次のコードはエラーを生成せず、前のコードと同じように機能します:
1. $str = "u202e"; // 正确

関連 RFC:

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

エラー処理の変更

現在、 Exception と Error という 2 つの例外クラスがあります。どちらのクラスも新しいインターフェイス Throwable を実装します。この状況を処理するには、例外処理コードの型ディレクティブを変更する必要がある場合があります。
一部の致命的エラーおよび回復可能な致命的エラーは、代わりにエラーをスローするようになりました。 Error は Exception とは別のクラスであるため、これらの例外は既存の try/catch ブロックではキャッチされません。

回復可能な致命的なエラーは例外に変換されるため、エラー処理で黙って無視することはできません。場合によっては、タイプ指示の失敗を無視できなくなります。
解析エラーにより、 Error extended 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 は未定義ですが、非推奨のヒントを使用してその呼び出しが許可されます。例:
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
これは、互換性のないコンテキストからの呼び出しでのみ発生することに注意してください。クラス B がクラス A から拡張された場合、呼び出しはプロンプトなしで許可されます。
次のクラス名、インターフェイス名、特殊名 (大文字と小文字は区別されます) は使用できません:
1. bool
2. int
3. float
4. string
5. null
6. false
7. true
これは、クラス/インターフェイス/トレイトの宣言、class_alias()、および use ステートメントで使用されます。

さらに、次のクラス名、インターフェース名、特殊名は将来の使用のために予約されていますが、使用時にエラーはスローされません:
1. resource
2. object
3. mixed
4. numeric
で使用する場合、yield ステートメント構造では括弧が必要なくなりました。式コンテキスト。これは、「print」と「=>」の間で優先される右結合演算子になりました。これにより、場合によっては異なる動作が発生する可能性があります。例:
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;
この状況は括弧を追加することで解決できます。
ASP (<%) タグとスクリプト (