PHPの将来の可能性

wikimediafoundation.orgから撮影した画像

翻訳者から ：この投稿は、ownCloudの創設者であり、クラウドストレージを作成するためのオープンソース製品の開発者であるFrank Karlitschekによって書かれたPHPの将来の可能性に関する記事の無料翻訳です。

最新の統計を見ると、OwnCloudはPHPで書かれた最大のオープンソースプロジェクトの1つです。 ほとんどの人は、PHPがOwnCloudのサーバー側の実装に使用されていることを知っています。 デスクトップクライアントにはC ++とQt、AndroidアプリケーションにはJava、iOSにはObjective-C、WebインターフェイスにはJavaScriptなど、他のテクノロジーを使用しています。 しかし、OwnCloudの中心はPHP 5.3以降に基づいたサーバーコンポーネントです...







PHPを選択する理由はいくつかあります。

• OwnCloudの主な目的は、全員に独自のクラウドサーバーを提供することです。 PHPは、ほとんどのWebサーバー、オペレーティングシステム、およびプラットフォームで利用可能なテクノロジーです。 また、PHPで記述されているため、OwnCloudサーバーのホスティングが非常に簡単になります。
• PHPはスクリプト言語です。つまり、1つのtarアーカイブがすべてのプラットフォームで動作し、複雑なコンパイルやアセンブリはありません。
• PHPは非常に有名です。 多くの人がPHPに精通しています。 また、PHPを知らない開発者でも簡単に学習できます。 参加者の要件のレベルはできるだけ低くする必要があるため、これはオープンソースプロジェクトにとって非常に重要です。
• PHPは、適切な方法で使用すれば強力かつ高速です。 ウィキペディア、Facebook、WordPress、一部のYahooなどの多くの大規模なWebプロジェクトはPHPで作成されています。 したがって、あなたはそれに多くを行うことができます。 残念ながら、悪いコードも比較的簡単に書くことができます。 しかし、それについては後で。
• PHPで利用可能なライブラリ、コンポーネント/ドライバーの巨大なエコシステムがあります。 OwnCloudのようなオープンソースプロジェクトの場合、これは非常にクールです。これは、すべてをゼロから作成する必要がないことを意味します。 私たちは巨人の肩の上に立ちます。

PHPは、世界で最も「ヒット」しているプログラミング言語ではありません。 実際、逆のことが当てはまります。 彼は比較的悪い評判を持っています。 個人的には、「クール」、「モダン」、または「ファッション」であるという事実に基づいてテクノロジーを選択する大ファンではありません。 分野ごとに異なる技術があり、それらは客観的に評価されるべきであり、感情の関与なしに選択される必要があると思います。 したがって、ツールXが常にテクノロジーYよりも優れている理由についての宗教的な議論を理解していません。もちろん、これらすべては、それらを使用する知恵を公正に評価した上で機能する適切なテクノロジーだと思います。



したがって、私はPHPを使用するというこの決定に非常に満足しています。 これまでのところ、PHPで解決できない主要なアーキテクチャまたは技術的な問題は発生していません。



しかし、これはPHPが完璧であり、すべてに非常に満足しているということですか？ もちろん違います。 PHPは90年代半ばに開発されました。当時は、Webが今日のように想像できませんでした。 当時の興味深い機能の一部は、今日悪夢に変わりました。 改善する必要のあるものはたくさんあります。PHPの中核開発者でさえ、ここで私に同意すると思います。



明らかな欠陥：

• 安全性 PHP自体は安全ではありませんが、美しく安全なコードを書く機会です。 PHPは、セキュリティに対してやや素朴なアプローチを実装することを決定し、安全なコードの作成において開発者をあまりサポートしていません。 公平に言うと、90年代には誰もがWebセキュリティについて世間知らずでした。 したがって、PHPには開発者が安全なコードを書くのを助ける機会はあまりありません。 たとえば、データベースとの混同、多くの人々はまだバインド変数を使用していないため、おそらくSQLインジェクションの出現を許可します。 また、XSSおよびその他の考えられる問題の入力フィルタリングは、開発者が手動で解決する必要があります。 これらすべての問題を解決するのに役立つ拡張機能とライブラリがありますが、それらは言語/カーネルの一部ではないか、問題を完全に解決しません。
• コンパイル/構成。 楽しみのために、。/ configureスクリプトを実行してPHPをコンパイルし、すべてのコンパイルオプションを確認します。 サーバー管理者がphp.iniで設定できるオプションを見てみましょう。 一方で、管理者はPHPの機能の大部分をかなり簡単に有効または無効にできるため、これは良いことです。 しかし、PHP開発者にとって、利用可能なすべてのPHP対応サーバーで実行する必要があるアプリケーションは悪夢です。 どの機能が使用可能かつアクティブであるかは決してわかりません。 OwnCloudには、環境とランタイムに依存する多くのコードがあり、すべてが正常に機能するか、必要に応じて適応するかをチェックします。 残念ながら、これは安定したプラットフォームや優れたOS抽象化と呼ばれるものではありません。
• 関数とクラス名にいくつかの矛盾があります。 下線が使用されることもあれば、キャメルケースが使用されることもあります。 一部の機能は手続き型で利用でき、一部はOO APIを備えており、一部は両方ともあります。 クリアする必要があるものがたくさんあります。
• 静的タイピング。 もちろんこれは好みの問題ですが、時にはもっと静的な型付けをしたいことがあります; PHPではもう少し静的な型付けをしたいです。 ディレクトリに「0」という名前のファイルがある場合、次のコードの動作を推測します

while ( ($filename = readdir($dh)) == true) $files[] = $filename;







PHPの次のレベルに移行し、将来これらの欠点のいくつかを改善することを本当に望んでいます。

しかし、それを正しく行うことは非常に重要です。



ArsTechnicaとAppleの最後の記事では、Objective-Cの後継としてSwiftの実装を推進しています。ここでは、次世代のPHPをどのように実行できるか、また実行すべきかを想像しています。

後方互換性を維持するか、欠陥を修正しますか？ -Apple Swift



今、古い、率直に言って、非常に素朴なアプローチがあります。 プログラミング言語の開発者の中核チームは、古いバージョンの欠点を修正する新しい非互換バージョンをリリースするだけです。 例は、PerlおよびPythonです。 問題は、これらの言語で書かれたソフトウェアプロジェクトのほとんどを新しいバージョンと互換性を持たせるために書き換えることがほとんど不可能であることです。 したがって、非常に長い間、プログラミング言語/フレームワーク/アプリケーションの2つのバージョンで作業することになります。 また、一部のアプリケーションは古いバージョンで動作し、古いバージョンで動作します。 1つのバージョンのみで異なるライブラリの依存関係が利用できる場合があります。



移行は非常に難しく、部分的に完了することはできません。 これが悪夢になる例については、Perl6とPython 2/3を参照してください。 どちらも非常に長い間存在し、多くのプロジェクトは移行ルートの途中で「スタック」しています。



よりポジティブな例はC ++です。 Cとは大きく異なりますが、アプリケーション内で混合して使用できると便利です。 したがって、90年代のC開発者は、アプリケーション全体をゼロから書き直すことなく、アプリケーションの一部で新しい興味深いC ++関数を使用できます。



AppleはSwiftをObjective-Cの後継として進めていますが、これは非常に賢明だと思います。 結局のところ、これはまったく新しい言語ですが、同じランタイムで動作します。 つまり、開発者は既存のObjective-Cアプリケーションコードを取得して、新しいSwift関数の作成を開始するか、古いコードの一部を新しいSwiftコードで他のコードに置き換えることができます。 最終的に、これはバイナリにコンパイルされ、Objective-Cと比較して新しいランタイム依存関係はありません。



PHPが言語の大幅な開発と改善を可能にすることを願っていますが、それでも完全に互換性のないリリースをリリースしたときに、PerlやPythonのようなスムーズな移行体験を提供しません。



また、PHP 6または7で新しい開始タグ（<？PHPの代わりに<？PHPNEXTなど）が導入された場合にも優れたソリューションになります。 両方のモードは、PHPの新しいバージョンで完全にサポートされ、同じアプリケーションまたは同じファイルで並行して使用できます。 また、PHPNEXTセクションでは、新しく改善された構文が使用されます。



ここに私が見たい改善のためのいくつかのアイデアがあります：

• 安全性 _GET、_POST、_SERVER配列はなくなり、代わりに正しいAPIが表示されます。これを使用して、すべての受信データをフィルタリングできます。 （翻訳者注：現在、PHP 5> = 5.2.0でサポートされているfilter_inputがあります）
• データベース PHPは多くの異なるデータベースAPIをサポートしています。 それらのいくつかは非常に古いですが、使用には互換性がありません。 OO APIが1つだけになるように、すべてを標準化する必要があります。 個人的にはPDOを基礎として見たいです。
• 32/64ビット。 32ビットまたは64ビットのオペレーティングシステムで実行するPHPアプリケーションを作成したことがある人なら誰でも、変数、特に整数変数の動作が異なることを認識するでしょう。 これらはC / C ++のエコーであることを理解していますが、これは本当に悪い考えです。 個別にチェックする必要のあるコードの異なる部分は必要ありません。
• Safe_mode、open_basedir、およびその他の古代の概念はその ままになります（翻訳者注： safe_modeオプションは5.3.0で廃止とマークされ、5.4.0で削除されました）
• ほとんどのコンパイルおよび実行構成オプションは削除されます。 すべてのPHPNEXT環境は、できるだけ近く、安定している必要があります。
• タイピング。 PHPが追加の静的型付けを導入して、変数をboolまたはintとして宣言できるようになったら素晴らしいでしょう。 そして、何か他のものが使用されている場合、例外がスローされました。
• 常にUnicode文字列を使用するには

これらの改善のいくつかは、Facebookで開発された一種の別個のPHPブランチであるHackに実装されています。 ハックには、同じ方向に発展している非常に興味深いコンセプトがあります。 また、新しい「<hh」タグを使用するため、コードを1つのファイルに混在させることができ、タイピングも改善されました。 現時点では、Facebookが今後Hackをさらに開発するためにプロジェクトにどれだけの労力を費やし、Facebook以外でどのように受け入れられるかについては明確ではありません。 また、彼らにとって重要ではない変更に対して、彼らがどの程度オープンになるのか、誰がどのように規制するのかも心配です。 PHPコミュニティの公式でより一般的なアプローチを希望します。これは、次の主要なPHPリリースの一部になります。



スムーズな移行パスを含む、より近代的でクリーンなPHPの夢が、今後数年で実現することを願っています。



もちろん、OwnCloudでは、すべてのPHPインストールの95％が新しいバージョンで動作し始めるまで、この新しいPHPモードへの移行を開始できません。 簡単ですが、さらに3〜5年かかります。



WordPressやOwnCloudなどの大規模なプロジェクトを行うことで、実際には、よりクリーンで最新の言語に移行することができます。 しかし、もっと重要なのは、PHPが未来に挑戦する準備ができていることです。



UPD：5.4.0でsafe_modeの削除に関する注意を追加しました。 ヒントの Swayに感謝します :)、 filter_inputについてのメモ、 コメントの AmdYも追加しました。



UPD2：テキスト内のいくつかのエラーを修正しました。hDrummerのコメントに感謝します。