トーク

PHPはZend VMの上で動いており、すべてのPHPプログラムはそのopcodeに変換され実行されます。
本発表では、そのopcodeを眺めてみて、他の言語処理系との違いについてご紹介します。
発表者はいくつか仮想マシンを作ったことがあり、とくにRubyの仮想マシンについてちょっと詳しいので、そういった観点でご紹介できればと思います。
参加者の皆様には、他の言語処理系との比較を通じて、Zend VMの独自性や利点を理解していただければと思います。

2015年、PHPコミュニティは内戦状態でした。Scalar Type Declarations RFCは、賛成108票、反対48票という異常な投票数を記録し、厳密派と寛容派が激しく対立しました。なぜ最終的にstrict_typesは「ファイル単位のオプトイン」になったのでしょうか。

背景には、PHP 5.4で削除されたmagic_quotesの苦い教訓がありました。php.iniの設定次第で同じコードが環境によって異なる動作をし、SQLインジェクション脆弱性を生む原因となった経験から、PHPは環境依存の設定を避ける方向に舵を切りました。さらに、Composerエコシステムとの共存も不可欠でした。もしグローバル設定が可能だったら、vendorディレクトリ以下の数百のパッケージが想定外の動作モードを強制され、エコシステム全体が壊れる可能性がありました。

この設計は「漸進的型付け」という学術的アプローチに基づき、後方互換性、エコシステムの安定性、開発者の選択の自由を守りました。「全部ONにすべきか」という問いへの答えは、あなたのプロジェクトが決めることです。Whyを知るとHowの判断が変わります。

アーキテクチャの刷新は、しばしば「決める人」が限定され、トップダウンでの進行になりがちです。
しかし、その方法では納得感が生まれず、チーム全体が新しいアーキテクチャに適応しきれないのではと私は感じていました。

そこで実施したのが、「俺の/私の最強アーキテクチャ決定戦」というイベントです。
全員が発言できるように場を用意し、メンバーがそれぞれ考える理想のアーキテクチャを持ち寄る形式を取りました。

この取り組みには二つの意図がありました。

1. トップダウンにせず、チームで方向性を決めたかった
2. 不満や現状の違和感を、発言機会を設置することで可視化したかった

実際に開催してみると、若手メンバーからも積極的な発信があり、各自抱えていた困りごと・改善の種を吸い取ることができました。
最終的に決まったアーキテクチャはひとつですが、その結論には全員の声が反映された状態をつくれました。
これによりトップダウンでは得られない、「自分たちで決めた」という納得感とオーナーシップが生まれました。

本LTでは、
・なぜトップダウンではなくイベント開催を選んだのか
・どのように発言機会を設計したのか
・若手の声を拾うことで何が変わったのか

チーム全員が新しいアーキテクチャに適合するための工夫を実体験に沿って紹介します。
アーキテクチャ刷新は設計だけでは進みません。
“決め方”を設計することでチームは刷新に適応できるようになる。
そんな学びをお伝えします。

■想定する参加者層
・トップダウンの設計決定に違和感を覚えたことがある人
・若手の意見を引き出したいリーダー
・設計刷新や合意形成に悩むチームメンバー

■Learning Outcome
・チーム内での考える人作る人の分断を防止できる
・チームが主体的に開発を進めていける
・チームがオーナーシップを持ってプロダクトを育てていける

ProgateでPHPを学び、2ヶ月でCRUD処理ができる掲示板を作れるようになりました。しかし機能を追加するたびにコードは複雑化し、どこに何を書けばいいか分からなくなり、収集がつかなくなっては最初からやり直す日々。
この地獄を抜け出すために「フレームワーク」を調べ始めましたが、LaravelやSymfonyの説明を読んでもありがたみが分からないし、漠然と機能を覚えていく学習に面白さを感じませんでした。ならば自分で作ってみよう。
MVC、ルーティングのディスパッチャー、コンストラクタインジェクション、バリデーター、CSRF対策、自動XSSエスケープ、Laravel風のヘルパー関数—これらをゼロから実装する中で、特に「依存性注入のメリット」と「設定より規約」の考え方が腹落ちしました。
本トークでは、フレームワーク自作を通じてこれらを理解していった過程を共有します。

トークの内容：

• スパゲティコード地獄から、フレームワーク自作に至るまで
• 実装した機能の紹介
• 「設定より規約」： ディレクトリに置くだけで動く、コンストラクタに書くだけで再帰的インスタンス化
• 「依存性注入」： サービスプロバイダで実装の差し替え、テストの容易さ
• まとめ： 作ることで「なぜ必要か」が腹落ちした

__get() 経由で読み取り可能な protected プロパティに対し、外部から empty() を使用した際、値が存在するにも関わらず true (空) が返ってくる現象に遭遇しました。

「直接アクセスでは値が取れるのに、なぜ empty() は空と判定するのか？」

調査の結果、原因は empty() 関数の内部仕様にありました。
empty() はアクセス不能プロパティに対し、いきなり get() で値を取りに行くのではなく、まず isset() で存在確認を行います。
ここで __isset() が未定義だと、問答無用で「存在しない＝空」と判断されていたのです。

本LTでは、この意外なハマりポイントの解説と、get() を使うなら必ず isset() も実装すべきという「お作法」について、実例を交えて共有します。

※PHP7.4のお話です。
8.1以降なら public readonly でプロパティを定義すれば __get() とか使わなくて良いはずですが、実際には8.1まで上げられていないプロジェクトもあると思うので…。