PHP 7.4.0發佈!一塊兒看看有哪些新特性

PHP 7.4.0 發佈了,此版本標誌着 PHP 7 系列的第四次特性更新。php

看了英文手冊後,發現其進行了許多改進,並帶來了一些新特性,如今將這些新特性您:laravel

 

1.Typed Properties 類型屬性數組

類屬性如今支持類型聲明,如下示例將強制 $User-> id 只能分配 int 值,而 $User-> name 只能分配 string 值。緩存

<?php

class User {

    public int $id;

    public string $name;

}

?>

● 它們自PHP 7.4起可用。服務器

● 它們只在類中可用,而且須要訪問修飾符:public、protected、private、var。閉包

● 除了void和callable以外,全部類型都是容許的。app

PHP是咱們喜歡和討厭的一種動態語言,它將強制類型轉換作的太好,有時也會引發副作用。假設您在指望整數的地方傳遞了一個字符串,PHP將嘗試自動轉換該字符串:composer

class Bar

{

    public int $i;

}

$bar = new Bar;

$bar->i = '1'; // 1

若是不喜歡這種行爲,能夠經過聲明嚴格類型來禁用它:框架

declare(strict_types=1);
$bar = new Bar; $bar->i = '1'; // 1
 Fatal error: Uncaught TypeError: Typed property Bar::$i must be int, string used

 

2.Arrow Functions 箭頭函數ide

箭頭函數提供了用於定義具備隱式按值做用域綁定的函數的簡寫語法。

<?php

$factor = 10;

$nums = array_map(fn($n) => $n * $factor, [1, 2, 3, 4]);

// $nums = array(10, 20, 30, 40);

?>

● 自PHP 7.4起可用

● 他們以fn關鍵字開頭

● 它們只能有一個表達式,即return語句

● 不容許return關鍵字

● 參數和返回類型能夠是類型提示

您沒看錯:短閉包只能有一個表達式。這意味着您不能包含多行。

理由以下:

簡短閉包的目標是減小冗長。fn固然在全部狀況下都比function短。然而,若是您處理的是多行函數,那麼使用短閉包所得到的好處就更少。

畢竟,按照定義,多行閉包已經更加冗長;所以可以跳過兩個關鍵字(function和return)不會有太大的區別。

 

3.Limited Return Type Covariance and Argument Type Contravariance 有限返回類型協變與參數類型逆變

僅當使用自動加載時,才提供徹底協變/逆變支持。在單個文件中,只能使用非循環類型引用,由於全部類在被引用以前都必須可用。

<?php

class A {}

class B extends A {}

class Producer {

    public function method(): A {}

}

class ChildProducer extends Producer {

    public function method(): B {}

}

?>

 

4.Unpacking Inside Arrays 打包內部數組

<?php

$parts = ['apple', 'pear'];

$fruits = ['banana', 'orange', ...$parts, 'watermelon'];

// ['banana', 'orange', 'apple', 'pear', 'watermelon'];

?>

 

5.Numeric Literal Separator 數值文字分隔符

數字文字能夠在數字之間包含下劃線。

<?php

6.674_083e-11; // float

299_792_458;   // decimal

0xCAFE_F00D;   // hexadecimal

0b0101_1111;   // binary

?>

限制

惟一的限制是數字文字中的每一個下劃線必須直接位於兩個數字之間。這條規則意味着下面的用法都不是有效的數字文字:

_100; 

100_;       

1__1;       

1_.0; 1._0; 

0x_123;     

0b_101;     

1_e2; 1e_2; 

PHP功能不受影響

在數字文字的數字之間添加下劃線不會改變其值。下劃線在詞法分析階段被刪除,所以運行時不受影響。

var_dump(1_000_000); // int(1000000)

 

6.Weak References 弱引用

弱引用能夠保留對對象的引用,不會阻止對象被銷燬。

弱引用容許保留對對象的引用,而該對象不會阻止對象被銷燬;它們對於實現相似緩存的結構很是有用。

原則上,弱引用對象並不複雜,只須要(ab)使用Zend或下面的層,由於咱們不直接支持它。

final class WeakReference {

    public static function create(object $object) : WeakReference;
  
    public function get() : ?object;

}

 

7.Allow Exceptions from __toString() 容許從 __toString() 拋出異常

如今容許從 __toString() 引起異常,以往這會致使致命錯誤,字符串轉換中現有的可恢復致命錯誤已轉換爲 Error 異常。

7.4之前禁止從__toString()拋出異常,若是__toString()異常,將致使致命錯誤。

從技術角度來看,這種限制最終是無效的,由於字符串轉換期間的異常仍然能夠由將可恢復錯誤轉換爲異常的錯誤處理程序觸發:

set_error_handler(function() {

    throw new Exception();

});

try {

    (string) new stdClass;

} catch (Exception $e) {

    echo "(string) threw an exception...\n";

}

另外,將「不能轉換爲字符串」和「__toString()必須返回一個字符串值」可恢復的致命錯誤轉換爲正確的錯誤異常,這與PHP 7中創建的錯誤策略一致。

 

8.Opcache Preloading Opcache 預加載

新增 Opcache 預加載支持。

在PHP 7.4中,添加了對預加載的支持,這是一個能夠顯著提升代碼性能的特性。

簡而言之,這是它的工做方式:

● 爲了預加載文件,您須要編寫一個自定義PHP腳本

● 該腳本在服務器啓動時執行一次

● 全部預加載的文件在內存中均可用於全部請求

● 在從新啓動服務器以前,對預加載文件所作的更改不會產生任何影響

雖然預加載是創建在opcache之上的,但它並非徹底同樣的。Opcache將獲取您的PHP源文件,將其編譯爲「 opcodes」,而後將這些編譯後的文件存儲在磁盤上

您能夠將操做碼看做是代碼的底層表示,在運行時很容易解釋。所以,opcache會跳過源文件和PHP解釋器在運行時實際須要之間的轉換步驟。巨大的勝利!

但咱們還有更多的收穫。Opcached文件不知道其餘文件。若是類A是從類B擴展而來的,那麼仍然須要在運行時將它們連接在一塊兒。此外,opcache執行檢查以查看源文件是否被修改,並將基於此使其緩存失效。

所以,這就是預加載發揮做用的地方:它不只將源文件編譯爲操做碼,並且還將相關的類、特徵和接口連接在一塊兒。而後,它將這個「已編譯」的可運行代碼blob(即:PHP解釋器可使用的代碼)保存在內存中

如今,當請求到達服務器時,它可使用已經加載到內存中的部分代碼庫,而不會產生任何開銷。

爲了進行預加載,開發人員必須告知服務器要加載哪些文件。這是用一個簡單的PHP腳本完成的,確實沒有什麼困難。

規則很簡單:

● 您提供一個預加載腳本,並使用opcache.preload命令將其連接到您的php.ini文件中。

● 您要預加載的每一個PHP文件都應該傳遞到opcache_compile_file(),或者在預加載腳本中只須要一次。

假設您想要預加載一個框架,例如Laravel。您的腳本必須遍歷vendor/laravel目錄中的全部PHP文件,並將它們一個接一個地添加。

在php.ini中:

opcache.preload=/path/to/project/preload.php

這是一個虛擬的實現:

$files = /* 要預加載的文件數組 */;

foreach ($files as $file) {

    opcache_compile_file($file);

}

有一個警告!爲了預加載文件,還必須預加載它們的依賴項(接口,特徵和父類)

若是類依賴項有任何問題,則會在服務器啓動時通知您:

Can't preload unlinked class

Illuminate\Database\Query\JoinClause: 

Unknown parent 

Illuminate\Database\Query\Builder

這不是一個致命的問題,您的服務器能夠正常工做。但你不會獲得全部你想要的預加載文件。

幸運的是,還有一種確保連接文件也被加載的方法:您可使用require_once代替opcache_compile_file,讓已註冊的autoloader(多是composer的)負責其他的工做。

$files = /* 要預加載的文件數組 */;

foreach ($files as $file) {

    require_once($file);

}

還有一些須要注意的地方。例如,若是您試圖預加載Laravel,那麼框架中的一些類依賴於其餘尚不存在的類。例如,文件系統緩存類\ lighting \ filesystem \ cache依賴於\League\Flysystem\Cached\Storage\AbstractCache,若是您從未使用過文件系統緩存,則可能沒法將其安裝到您的項目中。

#有效嗎?

這固然是最重要的問題:全部文件都正確加載了嗎?您能夠簡單地經過從新啓動服務器來測試它,而後將opcache_get_status()的輸出轉儲到PHP腳本中。您將看到它有一個名爲preload_statistics的鍵,它將列出全部預加載的函數、類和腳本;以及預加載文件消耗的內存。

#性能

如今到最重要的問題:預加載真的能提升性能嗎?

答案是確定的:我進行了一些基準測試。

有趣的是,您能夠決定僅預加載代碼庫中常用的類。基準測試顯示,只加載大約100個熱門類,實際上能夠得到比預加載全部類更好的性能收益。預加載所有類,性能提高13%,而預加載熱門類,則提高有17%。

固然,應該預加載哪些類取決於您的項目。明智的作法是在開始時儘量多地預加載。

此外還有一些棄用,以及從核心中刪除一些擴展,詳情查看英文原版手冊:

https://www.php.net/manual/zh/migration74.new-features.php

相關文章
相關標籤/搜索