回答:
WordPressが将来のバージョンで完全にOOPになることは決してないと99.9999%の確実性で言うことができます。少なくともそのトピックはwp-hackersリストに何度も登場し、コアチームメンバーは関心を表明していませんそうする。
1990年頃からOOPのプログラミングと教育に関する私の個人的な経験を見ていると、コアチームに同意し、完全なOOPは間違いだと思います。私はかつてOOPの熱狂者であり、OOPは万能薬だと思っていましたが、それ以来、いくつかのコンテキストでは価値があるが、他のコンテキストでは邪魔になると信じるようになりました。
OOPで私が見つけた最大の問題の1つは、開発者が実際にその構造を理解するずっと前に構造を焼き付けることであり、それが壊れやすい基本クラスの問題につながることです。
もちろん、WordPressの選択された側面については、OOPは非常に理にかなっています。コアを勉強すると、そのようなクラスが見つかります。Widget
、List_Tables
(3.1)など
この時点で、ほとんど非OOPパラダイムでWordPressを使用できてうれしいです。もしそれが純粋なOOPだったら、WordPressは次のようにはならなかったでしょう。どうして?OOPは、WordPress志望者やプラグイン開発者の複雑さの水準を引き上げる可能性があり、コアチームが過去にユーザーのニーズについて多くのことを学んだため、進化するのに十分な柔軟性を持たないアプリケーションになる可能性が高いためです6年間。
FWIW。
多くのWPコンポーネントは、新しいリリースごとにOOPコードで書き直され、新しいコンポーネントはそれを利用する傾向があります(たとえば、WP_Customizer
もの)。しかし、WPがそのアーキテクチャを完全にオブジェクト指向のアーキテクチャに変更するかどうかを尋ねている場合-いいえ、現在、そのようなことを示唆する情報はありません。
私はこれまで決して起こらないとは言いませんが、近い将来、おそらく「ベースクラス」の問題のためではないでしょう。
まず、WordPressのようなCMSアプリケーションでOOPよりも手続き型コードを使用する場合の欠点は、単にそのようなアプリがプラグインを介して拡張されることだけであるためです。関数とグローバル変数を組み合わせてスローしても、これが簡単になるわけではありません。WPが書かれた時点では、誰がWPになるかを予測することはできず、多くの不適切な選択が行われました。ほとんどのプラグインとテーマが適切に機能しなくなるため、追いつくのはかなり困難です。それを回避するために巨大な互換性レイヤーを実装すると、WPの速度が低下し、開発者間の混乱がさらに増える可能性があります。また、目的について考えてください-ユーザーの費用で、開発者の生活を楽にしますか?
役立つ場合-wp-hackers に関する非常に古い議論ですが、このトピックに関連するものであり、コミュニティによって提案されたアイデアは、現在「プラグインテリトリー」としてタグ付けされています。私は最近、この方向の他の活動に気付いていません。