Next XOOPS Cube 邦訳

プロジェクトのフォーラムに投稿した内容の邦訳です:

---- ここから ----

XOOPS Cube はまだバージョン 0.9 に留まっているため、私たちはフルバージョンを作るべきです。長い間、私は Legacy にかかりきりだったので、 XOOPS Cube の本質を見失ってしまいました。しかし今、私が自分の仕事に集中できたので、私は XOOPS Cube 設計の短所に気づきました。私たちは理想の XOOPS Cube のために未完成パートだけでなく既存設計の一部を変更するべきです。

私は休憩時間にこれらのポイントを整理しました。

1. XOOPS Cube controller は、 XOOPS の冠を自らに与えんがために X2 のシークエンスを見すぎました。Cube は OGRE にインスパイアされたのですから、私たちはコアをもっと OGRE に近づけるべきでした。
2. Cube はオブジェクト指向設計の表面に囚われています。原因のひとつは、私がウェブ技術のトレンドを反映させようと試みたことです。しかし、本来、コアシステムはトレンドに密接である必要はありません。私たちはもっと伝統的な技術を使うべきでした。たとえば、現在、デリゲートは万能と解され State、Strategy そして Listener の役割（存在）を曖昧にしてしまっています。
3. 私たちは PHP の性質について考慮する必要があります: ランタイム-コンパイル、ダックタイピング等
4. 最新の Web 開発のトレンドは「迅速な開発」ですが、私たちのトレンドは知識をオープンワールドで共有するための「モジューラブル設計」「換装可設計」であるべきです。
5. そのために、ウェブアプリケーションはシーケンシャルな処理ですが、私たちはいかにそのシーケンシャル処理を構築するかについて考慮するべきです: ジョブコントローラ、ソフトウェア（仮想）スレッディング。他方、 XCube_Service は並列処理に近いです。
6. XOOPS Cube における開発はいつでもどこでも優れたツールとともにあるべきです。

たとえば、 cubson によって生成される ActionFrame はウェブアプリケーションプロセスをすばやく扱うことが可能ですが、それは有限状態機械(FSM)としてみると奇妙な実装です。というより、ウェブアプリケーションのトレンドが現在厳密な FSM の実装を必要としていないといえます。しかしながら、もし私たちが伝統的なプログラミングパターンを使用すれば、ソフトウェア設計をめぐるファイトは起こらないでしょう。

言い換えれば、私たちはプログラムを作りましたが、私たちのプログラムデザインの正当性について考慮してこなかったということです。

現行の XOOPS Cube はライトウェイトとヘビーウェイトの中間地点にいます。私たちは XOOPS Cube が何で、 Base が何であるかを定義すべきです。私が思うに、 XOOPS Cube は Web のトレンドに囚われないヨソの＆伝統的なテクノロジーに基づいているべきです。そして、 Base モジュールは最新の Web アプリケーション設計のひとつであればよいでしょう。

熟練プログラマが地味にコツコツと作り上げたソフトウェアを想像してください。おそらくそれは特別なサプライズを備えてはいません。私たちにできるかどうかともかく、 XOOPS Cube はそのようなソフトウェアを目指すべきでしょう。

PHP プログラマは外来技術を避ける傾向があると聞きます。しかし、プログラマは未知に挑戦することが好きです。その外来技術が独自技術ではなく正当性のある技術に基づいてさえすれば、 Cube の設計に興味を持つでしょう。

私は Web 技術の詳細を知りませんが、そのような方法で XOOPS Cube をより良くする手伝いができると思います。

私が XOOPS Cube に必要だと思う何かは以下のとおりです。

• X2 シーケンシャルプロセスとの決別: executeCommon(), executeHeader() 等等
• MVC2 との決別（それは BASE に任せられればいい）
• 遷移制御責任からの決別: つまり、executeForward() や executeRedirect() を Cube のコントローラから取り除く
• マルチプラットフォームであれクロスプラットフォームではない（環境の実行時推測は行わない）
• そのために、 site_config.ini.php を使用した「ビルドオプション」の指定方法の体系化
• コード経路の体系化。おそらく、私たちはアクションフィルターのインスタンスに似た「ジョブ」を管理するジョブコントローラ（タスクコントローラ）を必要とします。
• コールバック手続きの体系化。おそらく、私たちは Delegate 以外に厳密な State と厳密な Listener を必要とします。リスナーは排他的 Delegate として使用されるでしょう。
• 個別のプログラム単位; ジョブとジョブの間のコネクタビリティを提供します。他方、開発者には独自の方法でジョブ間の通信を行うことを禁じます。
• 個別のプログラムのチェインの下では、 XOOPS Cube は「インオーダー実行」を保障する必要がありません。
• サービスはほかのプロセッサのジョブ、程度に位置づけ（並列処理扱い）ておきます。

さらなるリサーチのために二ヶ月ほど時間をください。

---- ここまで ----

ものすごく要約すると、XOOPS Cube 0.9 + Legacy は、さして PHP をリサーチしていない分際で「どうしたら PHP プログラマに違和感がないものに仕上がるか？」ということと「柔軟なライトウェイト言語を使いこなせない自分」の間の中途半端なものに仕上がってしまったと。次版は「どうしたら PHP の〜」の部分は各 BASE の実装に任せて、 XCube は外来技術概念といわれようがそれはそれでよそできちんとした考えなのだから、その経験を使ってなるたけ実直に組んでみたいということです。
たとえば、「配列のキーは ID で考える。 ID で考えると言うことは廃止番号があったら永久欠番になるということ」とか、「各グループ毎にアクセス可能なモジュールの ID をランタイム計算ではなく、変更時にあらかじめ抽出して保存しておく」とかです。こういう場合に、後者を「キャッシュ」と呼ぶと「うーん、なんか納得のいかない仕組みだなぁ」と言われそうですが、「ルックアップテーブル」と言い換えるだけで「ウン、ＯＫ！」ってなりそうな気がします。つまり、 PHP や Web というニューテクノロジに捕らわれず、先人が確立した技術とコトバの定義を共通認識としてうまく使っていこうということです。

そういう意味での（可及的）「実直」です。その中に PHP や Web やライトウェイト的に「ナシ」な要素があるかもしれませんが、変に妥協（恐れ）しないようにと考えています。よっぽど変であればフォーラムで指摘があると思いますし。

一方で、負荷を下げるという意味合いで、むやみにクラスばかり使うのではなくインナーでは配列を使ったり、PHPのダッチタイピング的な要素は容認していく（インターフェイスにこだわらない。C++だってハードの関係でパフォーマンスのボトルネックになる部分では純粋仮想関数をきっちり避けていく場合があるので）ようにしようかと思います。