Tag: php

PHP 8.2 預計要將一些字串內指定變數的方法標為 Deprecated，在 9.0 移除

Twitter 上看到這個蠻大的改變：

裡面的連結是「PHP RFC: Deprecate ${} string interpolation」，在文件中提到了 PHP 語言支援的四種字串內指定變數的方式：

  1. Directly embedding variables (“$foo”)
  2. Braces outside the variable (“{$foo}”)
  3. Braces after the dollar sign (“${foo}”)
  4. Variable variables (“${expr}”, equivalent to (string) ${expr})

提案在 PHP 8.2 裡將 3 與 4 兩種方式標為 deprecated，並且在 PHP 9.0 移除，目前看起來是 31:1 通過了...

PHP (以及 Laravel) 下使用 DynamoDB 的 ORM 工具

在 Twitter 上看到「Laravel DynamoDB Eloquent Models and Query Builder」這篇文章，裡面講「Laravel DynamoDB」這個套件，可以在 PHP (以及 Laravel) 下存取 DynamoDB。

雖然套件提到了 Laravel，但文件裡面也有提到支援非 Laravel 的 PHP 環境下使用，單獨拿出來用也沒問題，比較重要的反倒是 DynamoDB 對各種 key 的概念。

如果是從零開始設計，但又不想要自己管資料庫，我會偏好先用 RDS 設計，無論是 MySQL 或是 PostgreSQL 的版本都行，畢竟 RDBMS 上面能做的事情比較多，對開發者比較友善，除非是第一天上線你就預期量會大到連 db.m5.24xlarge 都擋不住之類的情況...

Laravel 9 (LTS) 出了

剛剛看到 Laravel 9 (LTS) 出的消息：「Laravel 9 is Now Released!」，對應的 release notes 在「Release Notes」這邊可以看。

相隔兩年半的 LTS 版本，另外也要求到 PHP 8.0+：

不過 Lavavel 的 LTS 設計上，沒有與一般 release 差太多，LTS 版本是 24/36 個月支援 (功能/安全)，但一般版本是 18/24 個月支援：

For LTS releases, such as Laravel 9, bug fixes are provided for 2 years and security fixes are provided for 3 years. These releases provide the longest window of support and maintenance. For general releases, bug fixes are provided for 18 months and security fixes are provided for 2 years.

如果看隔壁 Ubuntu 的 LTS 是 60 個月，但一般版本是 9 個月；Node.js 的 LTS 是 36 個月，以及一般版本的 9 個月，這樣看起來就有很明顯的差異...

這樣看起來跟一般版本好像也還好？

PHP: The Right Way

在 Hacker News 上面意外看到「PHP – The Right Way (phptherightway.com)」，官網在「PHP: The Right Way」這邊，另外我在 2012 年的時候也有提過這個站台：「PHP 康莊大道」。

看了一下，應該不完全是給初學者看的，反而對於回鍋的人比較有用，無論是很舊的歷史 (像是裡面提到的 PEAR)，還是比較新的東西 (像是 test case 那邊的介紹)，他都有花一些篇幅介紹，而且除了開發以外也包含了 deployment 與 hosting provider 的部份...

沒想到這個網站過了十年繼續維護啊，而且內容豐富不少...

PHP 的 Git Server 被打穿，決定把整個 Git 系統搬到 GitHub 上

就如同標題說的：「Changes to Git commit workflow」，Hacker News 上的討論也可以看一下：「PHP's Git server compromised, moving to GitHub (php.net)」。

Yesterday (2021-03-28) two malicious commits were pushed to the php-src repo [1] from the names of Rasmus Lerdorf and myself. We don't yet know how exactly this happened, but everything points towards a compromise of the git.php.net server (rather than a compromise of an individual git account).

While investigation is still underway, we have decided that maintaining our
own git infrastructure is an unnecessary security risk, and that we will
discontinue the git.php.net server. Instead, the repositories on GitHub,
which were previously only mirrors, will become canonical. This means that
changes should be pushed directly to GitHub rather than to git.php.net.

不知道發生什麼事情，要等事後的報告出來...

PHP 的 empty()

在 Nuzzel 上看到的文章，講 PHP 裡不應該使用 empty()：「When to use empty in PHP? I’d say never」。

之前寫 PHP 時很習慣用 === 與 !== 比較，另外習慣用 is_type() 先判斷型態再去搭其他的判斷 (像是 is_array() 與 is_string() 這類型態確認)，算是避免了文章裡面提到的問題，而且也提高了程式的可讀性 (因為開發者看到 is_type() 可以預期型態)。

比較討厭的應該是偶而還是會搞混 + (數字相加) 與 . (字串串接)，還有 + 對兩個數字字串是可以操作的 (然後會傳回 int)：

$ php -a
Interactive mode enabled

php > var_dump('123' + '456');
int(579)
php >

用過都說幹 XD

PHP 8.0 快要出了

看到 WordPress 的這篇「WordPress and PHP 8.0」，看起來 PHP 8.0 快要出了：

PHP 8.0 is in the final stages of its release cycle. As of the publish date of this post, version 8.0 RC5 has been released, and the final release of PHP 8.0.0 is scheduled for November 26, 2020.

官網上已經有一些資料可以看了，不過記得畢竟還沒 release，裡面的資訊還有可能會修正：「Migrating from PHP 7.4.x to PHP 8.0.x」，最重要的應該還是「Backward Incompatible Changes」這邊，可以看到這次畢竟是主版號升級，精彩的不相容性應該會搞爆不少應用程式，像是開頭就提到的，對數字與文字之間的 == 行為改變：

比較好的作法是自己先轉型再用 === 比較，這個概念在各家程式語言都類似，loose comparison 只是方便而已...

PHP 在 Amazon EC2 的 m5 (Intel) 與 m6g (ARM) 的效能差異

先前在「Amazon EC2 的 M6g 系列正式推出了」這邊提到了 AWS 在 Amazon EC2 上推出了以 ARM 為架構的 m6g 系列機器，剛剛看到有人拿 PHP 上的應用丟出測試的差異了：「Improving performance of PHP for Arm64 and impact on Amazon EC2 M6g instances」。

最先要注意的應該是這張：

在 PHP 7.3 的時候 Intel 平台的 m5 跑比較快，但到了 PHP 7.4 就變成 ARM 的 m6g 跑比較快了，不過這兩個版本的差異都不算太大，而到了還在開發的 PHP 8 則是出現了比較大的差距。

作者有提到主要的原因是在 PHP 7.4 之前 ARM 上不會啟用 Zend optimizer，而這個功能對效能的影響差很多，在 PHP 7.4 打開後就反轉了：

Zend optimizer is a component of the PHP runtime system that improves performance by up to 30% on a range of Zend micro-benchmarks. Before PHP 7.4 the Zend optimizer was not enabled for Arm.

而 PHP 8 的差距拉大，則是因為 PHP 有更多針對 ARM 平台的改善，像是這邊提到的 NEON 指令集：

PHP-8 plans to release in 2021 with more improvements for Arm64: an improved toupper/tolower function brings performance up by 16.5x. https://github.com/php/php-src/pull/4439

除此之外，AWS 也對 PCRE2 提供了使用 NEON 指令集的加速的 patch：

AWS has contributed changes to PCRE2 release 10.34. PCRE2 version 10.34 is used in PHP-8 to match regular expressions. PCRE2 accounted for about 8% of execution time in WordPress benchmark. The change contributed by AWS to PCRE2 vectorizes first character match and matching pairs of characters with NEON instructions: performance improves by up to 8x on M6g.

這樣可以看到 ARM 平常應該會愈來愈成熟，而更重要的是 m6g 系列機器比 m5 便宜不少：以作者測試的 {m5,m6g}.4xlarge 來看，分別是 USD$0.768/hr 與 USD$0.616/hr，大約是 20% 的差距，加上效能上的差距，C/P 值看起來是真的有到官方宣稱的 40%，這點在其他 Plurk 也測出了類似的結果：

未來除非是 binary-only 的東西，不然應該會朝著往 ARM 上面測過，再決定要怎麼選 instance type...

PHP 8 將會移除 XML-RPC，改放到 PECL 內

Twitter 上看到「PHP RFC: Unbundle ext/xmlrpc」這則消息，PHP 官方打算把 XML-RPC (也就是 git repository 裡面的 ext/xmlrpc) 拆出去，移到 PECL：

Unbundle ext/xmlrpc (i.e. move it to PECL) without any explicit deprecation.

主要的考慮是在於目前的 library 已經年久失修：

ext/xmlrpc relies on on libxmlrpc-epi, which is abandoned. Even worse, we are bundling a modified 0.51, while the latest version is 0.54.1. This is exacerbated by the fact that the system library is usually built against libexpat, but the bundled library is likely to be built against libxml2 using our compatibility layer.

另外應該也是因為 XML-RPC 用的人不多吧，投票是沒什麼玄念的 50:0，而且在 Packagist 上面也可以翻到一些用 PHP 實做的替代品，拿 xmlrpc 這個關鍵字搜了一下可以看到一些...

PHP 8 的提案，將 JSON library 放入必須項目

Twitter 上看到的通知，這個提案將 PHP 的 JSON 列為語言的必須項目，目前的狀態是 Under Discussion：「PHP RFC: Always available JSON extension」。

以前沒有引入的一個原因是因為底層使用的 library 的授權 JSON license 不是 open-source license，這對於要打包出 binary 散佈時的問題很大 (跟其他 license 衝突)：

The Software shall be used for Good, not Evil.

在 PHP 7 之後，JSON 的實做決定改用 jsond (參考「PHP RFC: Replacing current json extension with jsond」)，這邊用的是 PHP License 授權：「LICENSE」，這個因素就緩解了。

而這個提案提議拔掉 ./configure –-disable-json 關閉 JSON library 的能力，把 JSON library 變成 PHP language 的一部份：

Make it impossible to disable the JSON extension through configuration or build options. Require that JSON be built statically instead of as a shared library.

這個提案如果通過的話，對大多數人應該還是沒什麼影響，因為一般在用的版本都會裝 JSON library。而且現在會透過 Composor 管理套件，很容易就會有 dependency 會用到 JSON 而需要安裝 JSON library，問題不太大...