SymfonyはPHP-FIGから離脱するのかな？

PHP 1人Advent2018

1人AdventのDay-5です。

adventar.org

PHP的にはそろそろPHP7.3が出るよ〜ってことで、明るい話をしたいなぁ！って頃だと思うのですが。。今日は「最近あったニュース」でいう事では、個人的にこちらも注目しています。

※ 本記事は、私が普段Symfonyやそのコミュニティに接していなかったり、PHP-FIGの動向・思想やメンバーの変遷についても過去から深く追っていた訳ではないので、間違いに気づいたりご指摘をいただけたら積極的に訂正していきたいスタイルです・・・

なお、書くにあたって情報を収集していたところ、とても良くまとまっている記事が見つかりました。
こちらもぜひご覧ください。

hub.packtpub.com

何が起きているのか？ / 事の発端

Remove Symfony by fabpot · Pull Request #1120 · php-fig/fig-standards · GitHub

From 6fea4246955bf33648579f6822146dd49b48383e Mon Sep 17 00:00:00 2001
From: Fabien Potencier <fabien@potencier.org>
Date: Tue, 20 Nov 2018 19:19:51 +0100
Subject: [PATCH] Remove Symfony

---
 personnel.md | 2 --
 1 file changed, 2 deletions(-)

diff --git a/personnel.md b/personnel.md
index a7a48d684..519bd1360 100644
--- a/personnel.md
+++ b/personnel.md
@@ -67,7 +67,6 @@ Feel free to contact the secretaries at info AT php-fig.org. For more informatio
 | [Stash]                           | Robert Hafner ([@tedivm])             |
 | [Stormpath PHP SDK]               | Brian Retterer ([@bretterer])         |
 | [SugarCRM]                        | Andreas Sandberg ([@yellowandy])      |
-| [Symfony]                         | Fabien Potencier ([@fabpot])          |
 | [Flow] and [Neos]                 | Karsten Dambekalns ([@kdambekalns])   |
 | [Wikibase] and [Semantic Media]   | Jeroen De Dauw ([@JeroenDeDauw])      |
 | [Yii framework]                   | Alexander Makarov ([@sam_dark])       |
@@ -214,7 +213,6 @@ Feel free to contact the secretaries at info AT php-fig.org. For more informatio
 [Stash]: http://www.tedivm.com/stash
 [Stormpath PHP SDK]: http://www.stormpath.com
 [SugarCRM]: http://developers.sugarcrm.com/wordpress
-[Symfony]: http://www.symfony.com
 [The League of Extraordinary Packages]: http://thephpleague.com
 [Wikibase]: http://www.wikiba.se
 [Yii framework]: http://www.yiiframework.com

ということで、中々にインパクトのあるdiffだな！という内容のPRが、提出されました。

本題に入る前に

蛇足っぽいのですが、この話のスコープをはっきりさせるためにいま一度整理します。

PHP-FIGについて

PHP-FIGは、 PHP Framework Interop Group という集団です。
もともとは、「PHPに標準を送ろうぜ！」みたいな動機で集まってきました(雑)。
発足とそのあとの歴史については、この記事にまとまっているので御覧ください。

www.sitepoint.com

諸々を端折って、今は、「FIG」を名乗っているわけです。その目的は、(過去の反省を踏まえて「より柔軟・踏み込んだ提案をしていく」というスタンスに基づき)「フレームワーク間の相互運用を推し進める」ことにあります。

例えばPSR-0 autoloading standard *1などは、「PHP5.3で名前空間が入って、便利だけど、命名規則とかばらけちゃうとね」「もっとポテンシャル生かしてちゃんと使いたいよね」といった問題意識に端を発している訳です。
今では後継のPSR-4がPHPの「スタンダード」ですが、composerを含む「多種多様なライブラリを気軽に使える」エコシステムは、こうした提案力を持った存在により成立・推進されている面は大いにあると思います。ライブラリの作者からしても、より汎用性の高いものを作る上で、明確に「よくある」といえる実装やパターンがあると助かることもあるのではないでしょうか。そして、ライブラリの作成に関わる人数が増え、手が増えていくことで質の高いソフトウェアも生まれ・・・というサイクルがあると思います。

PSRについて

PSRは、有力なフレームワークの代表者や個人といった有識者が採択などを行っています*2。 その内容には、コーディングスタイルのガイドからキャッシュの使い方、DIコンテナに関する議論まで多岐にわたります。
これを「利用者が増えてくれば、その利用者の受ける恩恵は増えていく」というのを理想としてはいると思いますが、必ずしも「参画したら従うこと」と取り決めているわけではありません。
PHP-FIGホームページに有るFAQを見ると、以下のように記述がされております。

[Q] Do voting members have to comply to the standards?
[A] No. Becoming a voting member on the PHP-FIG in no way forces a member or project to implement every - or any - accepted PSRs. Projects have to consider backwards-compatibility issues when upgrading and make the changes at the right time, so it is assumed most projects will eventually adopt, but it is not a requirement.

Frequently Asked Questions - PHP-FIG

「強制的に従わなくちゃいけないものでもないし、互換性とかあると思うし、使うものを好きに選んでね」という話になっています。

PHP-FIGは、様々なプロジェクトが「相互運用性を尊重」した作成するための共通基盤として、素晴らしいやり方「だった」

さて、件のツイートに立ち返ってみます。

Fabien Potencier氏(@fabpot)はSymfonyのオリジナルの作者で、SynfonyはPHP-FIGのメンバープロジェクトです。「PHPの世界でのメジャーが集まって方向性を決めよう」というPHP-FIGの性質上、歴史・知名度・普及度のいずれの観点から見てもSymfonyは重要なプレイヤーといえるでしょう。

そんな @fabpot 氏が、過去形で「相互運用性のため」に「よいもの だった 」と語っているわけです。

スレッドを見ると、何が「よく」て何が「悪かっ」たのかが語られています。

めちゃくちゃな超訳もどきにはなりますが、大体こんな事を言っています

  • PSR-0/4: autoloadingは、ライブラリを互いに乗り入れるための最高の1歩だった
  • PSR-1/2: conding-standardは、些末な事に気を取られずに上手くやるのを推し進めてくれた
  • PSR-11: containerは協働のための見本。私を含め、最初こそ批判的に見ていた人はいるが、既存PJをより簡単にDIに乗っけていくための落とし所を見つけることができた。

このあたりは、"相互"のためにという思想を体現しているな〜と賛成しているように見えます。
PSR-7/14に関する言及は、かなり批判的です。

www.php-fig.org

github.com

  • PSR-7は、相互運用のためのものではない。結局の所、なにか(FIGが)「新しいフレームワークを作り始めた」ようなもの
  • PSR-14も同じ道を辿るだろうな

なお、まだ私は具体的な言及を探してはいないのですが、PSR-7に対して「思想に反する」「やりすぎ」のような立場をとっているのですから、これを前提とした15/17/18についても「そうじゃない！」という感じなのかなーと思います。。

そして、「PHP-FIGは、もう(多様なプロジェクトの)相互運用のためのものでもないし、彼らが独自的なカラーを持ったフレームワークを作るためにあるんだ」とまで言います。

「相互運用可能な」とは

PHPは、言語自体の思想としても、多くのフレームワークにしても「互換性を保つ」ことを非常に大事にしているように感じます。また、先程述べたとおり、PHP-FIGも「後方互換性を尊重し、PSRを実装しない事は大いに有り得る(可能である)」としているわけです。

そのうちにあって、PSR-7(やPSR-14)が「終わりの始まり」とされているわけですが・・・
同じくSymfony勢から、Titouan Galopin氏のこのリプライが問題をわかりやすく描き出します。

「既存のやり方を、寄せていく道がない。そんなのは、「相互運用」とは言えないでしょう。」という失望を感じます。

PHP-FIGはどうなっちゃうの・・？

PR自体はまだマージされていないのですが、これ離脱しないシナリオあるのかな・・・・
FIGは、過去にLaravelやGuzzle、Auraといったプロジェクトが離脱しています。そこに今回のSymfonyの離脱となると、「いろんなフレームワークとかでよく見かける名前」が大きく減りそうだなぁ、と個人的には感じるところ。これらのプレイヤーたちが「PSRに物申す」立場でなくなっていくというのは「策定されたPSRを利用する」可能性も落ちるわけで、「PSRってあまり見かけないよね」な状態になってしまったら・・存在意義が問われそうです。

また、実装(API)が揃っていても、現実的には、結局の所「どこへでも、持ってきてすぐに使える」という状況は作れていないし今後もそうなのだと思います。それも踏まえ、「必要とされる共通のインターフェイスとは」については、今までと少し考え方が変わっていくのでしょうか・・・・？

「やりやすくするため」の仕組みづくりだと思うので、「やりにくいから抜ける」というのは悲しみがありますね・・

*1:これがまさに、「PHP Standards Group」の当初の目的の1つ

*2:プロセスにはこちらを参照 https://www.php-fig.org/bylaws/psr-workflow/