アカウント名:
パスワード:
Case Insensitive …… 言語構造、名前空間、クラス、関数Case Sensitive …… 変数、配列キー、環境変数、プロパティ、メソッド、定数（定義による）
名前空間やクラスのオートローダー（読み込むパスの解決）はファイルシステムによる。
この辺の統一感の無さは、諦めるしかない。
const bool = 'hoge';function bool() { echo 'fuga';}echo bool; // hogebool(); // fugaecho (bool) bool; // 1
予約語のような、そうでないような。使われ方によって異なる実体（定数や関数やクラスや…）を指すのも、PHP の callable の闇の一因。
WordPress みたいな巨大システムでは、プラグイン A とプラグイン B が、同じライブラリの別バージョンをそれぞれ利用するケースがあっても、ハードコーディングされた名前空間（やクラスや関数）を動的に変えられないからコンフリクトを解消できない。
PHP に明るい未来はあるのだろうか？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
便利だけどクールじゃない仕様 (スコア:1)
Case Insensitive …… 言語構造、名前空間、クラス、関数
Case Sensitive …… 変数、配列キー、環境変数、プロパティ、メソッド、定数（定義による）
名前空間やクラスのオートローダー（読み込むパスの解決）はファイルシステムによる。
この辺の統一感の無さは、諦めるしかない。
const bool = 'hoge';
function bool() {
echo 'fuga';
}
echo bool; // hoge
bool(); // fuga
echo (bool) bool; // 1
予約語のような、そうでないような。
使われ方によって異なる実体（定数や関数やクラスや…）を指すのも、PHP の callable の闇の一因。
WordPress みたいな巨大システムでは、プラグイン A とプラグイン B が、同じライブラリの別バージョンをそれぞれ利用するケースがあっても、ハードコーディングされた名前空間（やクラスや関数）を動的に変えられないからコンフリクトを解消できない。
PHP に明るい未来はあるのだろうか？