PHPの将来に関する意見の1つ

最近、開発者のコ​​ミュニティでは、PHPとその将来に関連するすべてについて非常に活発な議論が行われています。 喜ばしいこと-これらの会話のほとんどは前向きな方法で行われます。 PHP 6とその外観についての議論は人気があります。 人々は、言語とコミュニティの将来におけるHHVMとその役割について多くの質問をします。 それで、これに関する私の考えのいくつかをあなたと共有させてください。

下位互換性について

次の各リリースは、前のリリースとの下位互換性を維持するために必要であると考えています。6、7、99、「象の愛好家」-好きな名前を付けてください。 そして、いくつかの非互換性が依然として発生するため、「主に」と言います。 しかし、これらの非互換性は正当化および制御する必要があります。 また、境界線のケースのすべての動作のレビューのみを目的とする必要があります。 これは、深刻な内部再編成ができないことを意味するものではありませんが、物事の純粋さと単純さを追求しています。 これは、非互換性が開発者を妨害しないことを意味します。



このアプローチは非常に簡単に検証できます。

記述したコードは、PHP 5.xとPHP 6.x（および2つの連続したメジャーリリース）の両方で問題なく実行されるはずです。

なぜこれが重要なのですか？ PHP 4からPHP 5への移行を見てください。PHP5への最終的な移行には約10年かかりましたが、プログラマーは両方のバージョンで動作するコードを書くのは簡単でした。 そして、これを行うことが困難だった場合、想像してみてください？



結局のところ、何も提示する必要はありません。 これはまさにPythonで起こったことです。 Python 3の最初のリリースは約5年前に発表されました。 そして今日、2014年、彼はまだ完全には関与していません。 悪いからではなく、両方のバージョンで問題なく動作する単一のコードを使用するのは非常に難しいからです。 つまり、Python 2、またはPython 3で機能する機能のいずれかを使用します（その結果、両方の利点が失われます）。 また、必要なライブラリまたはプラットフォームにPython 3のバージョンがない場合は、自分で移植する必要があります。まあ...運がありません。 実際、これがまさに起こることです。



私はこのアプローチが間違っているとは言いたくありません。言語はそのような変更から100万の異なるグッズを獲得します。 しかし、私にとっては、コミュニティと平均的なユーザーにとって、このような移行は依然として不必要に基本的なことです。

エンジンの書き換えについて

多くの人が言う：あなたはPHPエンジンを書き直す必要があります。 私は間違いなくこれをプラスと考えていますが（はい、エンジンは非常に洗練されています）、質問をしなければなりません：これは本当に必要ですか？ 基本的な犬はどこに埋葬されていますか？ 確かに、PHPエンジンにはアーキテクチャ上の計算ミスがありますが、全般的にはうまく機能します。



したがって、エンジンのコンポーネントベースへの移行、サブシステムへの分割を確認したいと思います。 今日、これはすでに部分的に行われています。 しかし、私はエンジンを本当にコンポーネントにする変更を見たいです。 なぜこれが重要なのですか？ このアプローチでは、個々の改善がエンジンの開発に大きく貢献できるためです。



例えば、現時点でPHPの最も混乱している部分は、パーサーとコンパイラーです。 それらは非常に密接に関連しており、混乱しているため、開発において多くの問題が生じます。 一方、それらがエンジンの個別のコンポーネントである場合、コンパイラーの置換がはるかに簡単になるというパーサー。 そして、それらの共通部分は、特定の抽象構文ツリーである可能性があります。 なぜASTなのか？ これは、両方のコンポーネントが使用できる一種の一般的なアイデアです。 はい、それは多くの仕事と良い仕事でしたが、利益は長くはかからなかったでしょう：一貫性があり、より予測可能な構文から、PHP自体を使用して独自の構文を定義する機能を追加すること（実際に言語）。



したがって、書き換える必要はありません。 リファクタリングとクリーン。

標準ライブラリのオブジェクト指向アプローチへの移行について

一部の人々は、標準のPHPライブラリをオブジェクト指向のアプローチに移行することを提案しています。スカラー型でさえオブジェクトの振る舞いをします。 つまり、次のようなものを書くことができます。

$string = "Foo"; var_dump($string->length); // 3 var_dump($string->toLower()); // string(3) "foo" // etc
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クールに聞こえるとは思いますが、これを行う必要はないと思います。



その理由は簡単です。スカラーはオブジェクトではありません。 しかし、最も重要なことは、それらはどのタイプにも属していません。 PHPは、文字列を整数とみなす型システムに依存しています。 システムの柔軟性は、任意のスカラー型を別のスカラー型に簡単に変換できるという事実にもあります。 もちろん、これは非常に多くのエラーが発生するため、常に良いとは限りません。



ただし、このような状況は、より具体的な動作によって解決できます。 たとえば、「ダーティ」型キャストを試行するときにキャッチ警告または例外をスローできるため、誰かが「123abc」を整数にキャストしようとすると、部分的なデータ損失に関するメッセージが表示されます。



さらに重要なのは、そのような型システムでは、特定の変数が特定の時間にどの型を持っているかを100％知ることができないということです。 さまざまなオプションを想定できますが、実際に何が存在するかは不明です。 これらの型は後で変更できるため、型変換後または言語がスカラー型のヒントをサポートしている場合でも、状況はあまり変わりません。



したがって、これはすべて、オブジェクト指向のアプローチでは、すべてのスカラー操作をすべてのスカラー型にバインドする必要があることを意味します。 これは、スカラーが数学的メソッドだけでなく、文字列を操作するメソッドも持つオブジェクトモデルにつながります。 なんてナンセンス...

HHVMになる

今日、この記事を書いている時点では、本番環境でHHVMを使用することはお勧めしません。 これにはいくつかの理由があります。 それらはすべて既知であり、基本的なものではありません。 それらが解決できるかどうかは時間が経てばわかりますが、私は本当にそう願っています。

1. HHVMは1つの会社によって管理されています。 誤解しないでください、問題はFacebookが開発に多額のお金を費やしているということではありません。 しかし、実際には、プロジェクトはHHVMを使用するかどうかに依存しないビジネスを営む会社によって管理されています。 彼らが有料サポートを提供し、HHVMを本格的な製品にした場合、それは1つのことです。 もう1つは、現在はオープンソースプロジェクトでも商用プロジェクトでもないことです。 そして、そのような状況で生産をHHVMに変換するとき、私は非常に緊張します。
2. HHVMには公開仕様がありません。つまり、一般に、Zendエンジンの場合と同じ方法でプログラミングします。 ただし、これは試行錯誤の方法です。複数の実装をサポートしようとするまではすべてうまくいくからです。 ライブラリ開発者として、私はすでに自分の肌でこれを感じていました。 一方、HHVMとPHPが最終的に何らかの共通仕様になった場合、多くのことがはるかに簡単になります...
3. HHVMはクローズドソースプロジェクトですが、サードパーティの開発者からのコードを受け入れます（既に良い）。 ただし、プルリクエストとパッチストリームはオープンソースプロジェクトを生成しません。 さて、プロセスの明確さはどこにありますか？ 視点の明確さはどこにありますか？ 参加の開放性はどこにありますか？ リーダーシップはどこにありますか？

同時に、私は自分の意見が私だけではないことを知っています。 HHVMは将来、強力な競争相手になりますが、上記の問題が解決されるまで、商業生産におけるHHVMの時代は到来していないと思います。

PHPとHHVMは共存できますか？

当然。 一部のテストは説得力がありますが、JITコンパイラは魔法ではありません。 彼らは私たちのこの現実の世界と妥協します：多くのテストがこれを明らかにします。 実際、テストの大部分をよく見ると、「実際の」コードを実行していないことに気付くでしょう。 ストップストップ、つまり、HelloWorldまたはフィボナッチ数ジェネレーターのパフォーマンスを比較しますか？！ さて、幸運を祈ります。今は落ち着いてください。そして、これらすべての無駄な結果を捨ててください。



実システムを使用しないテストは役に立たないことを繰り返しましょう。これはナンセンスであり、さらに悪いことです-それらは単に危険です。



実際には、HHVMがPHPよりもはるかに高速に処理できるタスクがあります。 しかし同時に、PHPがその速度を示すタスクがあります。 確認する唯一の方法は、アプリケーションをテストすることです。



しかし、HHVMは私のコードをネイティブとして実行します！ PHPはどのように高速化できますか？

JITは魔法ではないと言ったのを覚えていますか？ それで、これは実際にそうです。 PHPはインタープリター型プログラミング言語であるため、PHPを直接コンパイルすることはできません。 つまり、このコードを実行するまで、コンパイルキューにあるコードを正確に知ることはできません。 したがって、JITはまさにそれを行います。 実行可能コードを分析し、それに関する十分な情報を受け取って、ネイティブコードを生成します。 このプロセスはオーバーヘッドではありません。これは、コンソールでHHVMが遅いためです。



さらに重要なことに、JITは汎用コードを生成しません。 このコードが作成された時点で存在していた条件に従ってコードを生成します。 したがって、関数が2つの整数を追加する場合、そのようなコードは単純なaddステートメントにコンパイルできます。 ただし、コンパイラーは、整数型のパラメーターをチェックするための命令も追加します。 そして、関数に数値を渡すと（PHPの観点からは正常です）、チェックの1つが誤った結果を返します。



チェックの結果が偽の場合、「フェイルオーバー」のようなものが発生します。 簡単に言えば、エンジンはこのメソッド用にコンパイルしたすべてを「キャンセル」し、インタープリターモードに切り替えます。 このような操作の実行は、インタープリターモードでの一定の作業よりもはるかに高価です。



そして、これはJITコンパイラーが魔法ではない理由の1つにすぎません。



私がJITコンパイラーに反対していると今考えて欲しくありません。 それどころか、ほとんどのタスクでは、生産性が大幅に向上します。 しかし、それでも完璧ではありません。



他のコミュニティを見ると、JITコンパイラとともに仮想マシンの実装が表示されます。 CPythonとPyPyは良い例です。 Pythonには言語仕様があるため、ある実装を別の実装に簡単に変更できることにも注意してください。



しかし、ハックはクールです！

HackはFacebookによって開発され、HHVMに含まれる新しいプログラミング言語です。 大まかに言って、これはいくつかの追加機能を備えた静的に型付けされたバージョンのPHPです...



そして、ハックは素晴らしいです！ 私が示したHHVMの問題をどうにかして解決したいので、本当に貢献したいです！



結局のところ、これは興味深いアイデアです。 現在、PHPに基づいて構築されたいくつかのメタ言語があります。 リーダーはHackとZephirです。 しかし、問題があります。 両方とも特定のランタイム用です。HackはHHVM上で実行され、ZephirはPHP上で実行されます。 これを解決するには？



正直なところ、Zephirをドロップして、HackからPECLへのコンパイラーを作成するだけです。 Hackは静的に型付けされた言語であるため、HackとPECLの間にクロスコンパイル機能が必要です。 また、理論的には、Hackが既にC ++バインディング（システムライブラリの接続用）をサポートしていることを考慮すると、コンパイラーもこれを処理する必要があります。 この場合、PECL拡張機能を記述することは意味がありません。 拡張機能をHack（静的コードアナライザー、デバッガーを搭載）で記述し、完全に互換性のあるPECL拡張機能を生成します。 もちろん、このことは実装において非常に重要なことですが、試してみるのは素晴らしいことです！ ところで、ここで、言語仕様を支持する別の議論があります。

言語仕様について

おそらく、言語仕様の必要性についてテキストで何度か言及していることに気づいたでしょう...

これが、言語、プラットフォーム、エコシステム、およびコミュニティとしてのPHPの将来を改善するのに役立つ最も重要なものであることを示唆しています。

まとめると

PHPは、開発の非常に興味深い段階に入っています。 人々はクールなものを書き、進歩を促します。 したがって、PHPのさらなる成長が必要な場合は、これまたはその選択を行う際に何をしているかを非常によく理解する必要があると思います。