PHP-FIG 成立官方網誌

Twitter 上看到 PHP-FIG 成立 official blog「PHP FIG」了,放在 Medium 上:

另外有更正說明的 tweet:

是一個知道 PHP-FIG 又有什麼大事的管道...

PSR-7:HTTP message interfaces

PHP-FIG 前幾天公告了 PSR-7 (commit d40b64cc4e64e5a5b2fe998bb0a07d0b56e12505),也就是 HTTP message interfaces

由於 PSR 的編號只是提案順序,通過不一定會照順序。只是之前剛剛好都照著順序來 (PSR-0PSR-4),這次跳到 PSR-7 是跳過了 PSR-5 (PHPDoc Standard) 與 PSR-6 (Caching PSR)。

有了對 HTTP request 與 HTTP response 的標準後,可以馬上想到的是 routing library 與 controller library 可以接上去用,測試會變的簡單一些... 之後應該會有其他的想法可以做?

PSR-0 轉換到 PSR-4

在「Send PSR-0 to the Standards Farm in the Sky」這篇文章裡作者大聲呼籲用 PSR-4 取代 PSR-0

不過 PSR-0 在 Packagist 上被廣泛使用:

As of some time a few months ago (...), of the 20,097 packages hosted on Composer, 15,668 of them use PSR-0.

PSR-0 的設計是考慮到 PHP 5.2 沒有 namespace 時所留下來的特性 (以底線為主的切割方式),在 PHP 5.5 都已經出版,而且 PHP 5.2 已經 EoL 的時候顯得有點多餘。

作者提議在 PSR-0 的文件開頭加上:

Deprecated - As of 2014-12-30 PSR-0 has been marked as deprecated. PSR-4 is now recommended as an alternative.

不過 PSR-0 的專案應該還是會跑很久?

PSR-4

剛剛看到「Composer now supports PSR-4」才發現有 PSR-4,而且出了好幾個禮拜了...

PSR-4

This PSR describes a specification for autoloading classes from file paths. It is fully interoperable, and can be used in addition to any other autoloading specification, including PSR-0. This PSR also describes where to place files that will be autoloaded according to the specification.

在已經有 PSR-0 的情況下,設計 PSR-4 讓人感覺有點怪,因為功能跟 PSR-0 是衝突的。

不過仔細看看以後發現 PSR-4 規則比較「乾淨」,有種想要汰換 PSR-0 的想法... 而且 Composercomposer.json 的設計也允許針對不同的 prefix 使用不同的邏輯,看起來是把 PSR-0 當作過渡期的設計,希望大家換到 PSR-4?

PSR-0 與 PSR-4 最明顯的差異是對底線 (underscore) 解讀不同,在 PSR-4 中的底線沒有任何意義:

Underscores have no special meaning in any portion of the fully qualified class name.

在 PSR-0 裡則是說 class name 的底線必須換成 DIRECTORY_SEPARATOR:

Each _ character in the CLASS NAME is converted to a DIRECTORY_SEPARATOR. The _ character has no special meaning in the namespace.

來想看看要怎麼轉換現有的系統...

可能是未來的 PSR-3:LoggerInterface

Jordi BoggianoPHP-FIG 上提案整合 log interface,參考「One logger to rule them all」這篇,提案本身可以參考「Logger Interface」這裡。

如果通過的話,這很有可能是 PSR-3... 所以 PHP-FIG 接下來的想法是建立 interface 嗎?hmmm...

關於可維護的 PHP 專案:PHP-FIG 的 PSR-0、PSR-1、PSR-2

一個組織裡要導入 coding standatd & coding style 時是功夫最少的時候,除非有特殊理由,不然我一向都是建議:

不要自己發明 coding standard 與 coding style,如果社群的規範合理,就照著社群的規範走。

社群中比較完整的包括:

兩份大多數的規範是相同的 (因為 community 已經有習慣了),不過現在感覺起來 PHP-FIG 比較熱鬧一點 (參與的人來自不同的專案),如果讓我推薦的話我會建議用 PSR-{0,1,2}。

Reply to「寫出好維護的 PHP 程式碼」。