XOOPS Cubeコア リファクタリング案（XCube_Root）
K. Ono
minahitoさんよりCVS権限いただきましたので、リファクタリングを中心にコミットして
いきたいと思っています。
まずは件名のXCube_Rootです。
下記URLにある現在の最新のXCube_Rootに関して話を進めさせていただきます
http://xoopscube.cvs.sourceforge.net/xoopscube/XCube_PHP4/core/XCube_Root.class.php?view=log&pathrev=minahito_sandbox
現在のところXCube_Rootは
・各種サブシステムを作る
・各種サブシステムを保持する
・アプリケーションの設定ファイルを読み込む
・アプリケーションの設定を保持する
・アプリケーションを実行する
・ユーザコンテキストを作る
・ユーザコンテキストを保持する
・Base（Controller）を作る
・Baseを保持する
等の役割を担っていますが、今後の拡張や変更を考えて、それぞれ細分化していければと思います。
まずは、
・各種サブシステムを作る
・各種サブシステムを保持する
ですが、これはXCube_Rootの本来の役割だと思いますので、このままで。
次の、
・アプリケーションの設定ファイルを読み込む
・アプリケーションの設定を保持する
ですが、これは専用のライブラリを作っても良いのではないでしょうか。
例えば、
interface XCube_Config
{
function getConfig($key);
}
のような感じで。iniファイルはもちろん、配列やXML等から設定値を読み込む
ようにもできると思います。
XCube_Rootの初期化は
$root = XCube_Root::factory(XCube_Config $config);
のような感じで。。
・アプリケーションを実行する
これはControllerの役割ではないでしょうか？現在のXCube_Root::execute()
をそのままXCube_Controllerに持ってくれば良いのでは。そうすればLegacyのように
タスクシステムを使用しないBaseはexecute()をオーバライドすれば良いことになると思います。
・ユーザコンテキストを作る
・ユーザコンテキストを保持する
これは微妙ですね。イメージ的には、ユーザコンテキストがコントローラに渡されて、
その内容に応じてアプリケーションが実行されるという感じなので。。
また、$_GET等への直アクセスを防ぐためにも、例えば
XCube_Controller::execute(XCube_Context $context)
のような感じに、コントローラの必須パラメータとするのもありかもしれませんね。
・Base（Controller）を作る
・Baseを保持する
これも微妙ですね。。そもそもBaseを交換するということは、アプリケーションが
全く違うものになるので、アプリケーションのエントリーポイントも異なってきたり
しないのでしょうか？その場合には、Baseの初期化はエントリーポイント（index.phpとか）
に直書きというのもありかもしれませんね。
文章だと説明しにくいですね^^;
次回はコードを少しアップできればと思います。
minahito
onokazu さんありがとうございます。
> 次の、
>
> ・アプリケーションの設定ファイルを読み込む
> ・アプリケーションの設定を保持する
>
> ですが、これは専用のライブラリを作っても良いのではないでしょうか。
> 例えば、
>
> interface XCube_Config
> {
> function getConfig($key);
> }
>
> のような感じで。iniファイルはもちろん、配列やXML等から設定値を読み込む
> ようにもできると思います。
ですね！
抽象化はしていませんが、 ini 用に XCube_Config クラスは用意してあります。
Root が site_config の読み込みに使うとして、
他のプログラムが ini ファイルを読み込む場合に使えるかもしれませんね。
今度コミットしておきますので、抽象化案ください。
> ・アプリケーションを実行する
>
> これはControllerの役割ではないでしょうか？現在のXCube_Root::execute()
> をそのままXCube_Controllerに持ってくれば良いのでは。そうすればLegacyのように
> タスクシステムを使用しないBaseはexecute()をオーバライドすれば良いことになると思います。
タスクシステムの第一タスクが Controller になると考えていたのですが、
こっちでもいいかもしれませんね。
実は Controller という名前に最近抵抗がでてきたのですが、 Controller でも
大丈夫でしょうか。
0.9 では、ペリフェラルドライバの役割を ActionForm 、
プリロード機構を ActionFilter、そして XCube_Controller と名前を Web の
類似の存在にマッピングしたのですが、かえって混乱を招いてしまったのでは
ないかとちと反省しているところです。;;
逆に、突っ走ったレンダーシステム、レンダーターゲット、デリゲートなどは
初期こそ「なんじゃそりゃ！」となりましたが、割と意味がそのまま通ってい
ます。
> タスクシステムを使用しないBaseはexecute()をオーバライドすれば
これをやられてしまうと、
「PC に回ってもらうためにはタスクチェーンにつなぎさえすればよい」
という感覚で、共通ランタイムメカニズムをアテにするマルチBASE対応
プログラムが動かなくなっちゃいます。
できれば空っぽでもいいのでタスクシステムはまわしてくれという感じに
したいのですが……
それさえあれば、タスクシステムによるモジュールの実行共通化は、元が
スレッドスケジューラや SPURS の利用法からきてるアイデアですから、
確かにアプリのメインとは別にタスクシステムが回ったほうがイメージに
マッチします。
あとは、 0.9 → 1.0 の強化部の最大ポイントとして、
コアが稼動機構として弱いということに対する回答として、
プログラムがドライブしていく仕組みを XCube ルート側で（珍しく）固
定しちゃう。
だから駆動への合流方法もレンダリングプロセスも統一されるので、結構
安心してプログラムを書ける！
というのがあったんですが、ファーストタスクをコントローラに見立てる
のではなく、コントローラってものを明確に作って委譲しちゃうと当然そ
れはなくなるので、このあたりがどうなのか反応をみてみたいです。
（付け加えれば、XCube コアのレゾンデートル的に 1.0 で盛り込んだ固定
稼動のメカニズムに対する反応もまた得られてないのですが...
0.9風味も良いのですが、 1.0 案はマジでどうだったんでしょう）
> ・ユーザコンテキストを作る
> ・ユーザコンテキストを保持する
>
> これは微妙ですね。イメージ的には、ユーザコンテキストがコントローラに渡されて、
> その内容に応じてアプリケーションが実行されるという感じなので。。
コントローラが分離されれば、コンテキストはコントローラの下にあったほうが
よさそうですね。
問題は、タスクの粒度でコードを書いているときに、コントローラの下にある
ユーザコンテキストを取得しにいくことに違和感があるやなしや、といったと
ころかなと思います。
これはフィーリングの問題だから弄ってみないと分からないか……
> ・Base（Controller）を作る
> ・Baseを保持する
>
> これも微妙ですね。。そもそもBaseを交換するということは、アプリケーションが
> 全く違うものになるので、アプリケーションのエントリーポイントも異なってきたり
> しないのでしょうか？その場合には、Baseの初期化はエントリーポイント（index.phpとか）
> に直書きというのもありかもしれませんね。
えと、 Base を交換するという行為には、
Legacy のようにまったく違う Base に交換することもあれば、
Half-Life で Counter Strike を動かすように、メインシーケンスはほぼ同じで、
部分的に modify 状態になっているケースの２パターンがあるかと思います。
（HD_Controller みたいに）
onokazu さんが懸念されているのは前者かと思いますが、
ユーザーさんが活用するのは主に後者だと思うんです。
index.php に Base の初期化をハードコードしてしまうと、
site_custom.ini.php だけで交換するということができなくなっています。
（タスクシステムの利点は、シーケンスを初期化しながらでも構築できるので、
これができるところ）
そういう意味では今のサンプルのようにダミーででもファーストタスクを起動
して、 Controller があるなら、その中で Controller の初期化部を書いてもらうと
いうのもありだと思います。
ファーストタスクは site_config で指定できますし、タスクのコンストラクタの
シグニチャは決まっていますので...
そうすれば、生成や独自の初期化シーケンスはアプリ側で持つことができます。
# タスクシステムを使うアプリはだいたいこんな感じで
# 起動切り替えやモード切替をやってます。
タスクシステムも色々あると思いますが、仮にこの稼動がアプリケーション起
動より遅いとしても、
最悪でも site_custom.ini.php によるオーバーライドで設定が変更できるように
することは XCube 全体としてマストになればと思います。
なんべんか書いてますが、
将来的には設定ファイルはツールでぐりぐりと書き換えて、
気に入った設定をみんなで適当に交換するような利用イメージを描いてます。
ツール側からみれば XCube 全体で共通となっている ini を変更するのと、
index.php を書き換えるのでは難易度や致命度が違ってくるので、
たとえ Legacy のように index.php がぜんぜん違う BASE が登場したとしても、
設定ツールの基本機能はだいたい対応しているという具合のスペックが組め
ればと思います。
ほとんどはプログラム上の縛りというより、 Certification Requirements の
領域を出ないので、そういう BASE が出てくることをメカニズム的に抑制
することにパワーを使う必要はないですが、
XCube 開発を行う人間のいちおうの共通の心積もりとして、ユーザーエク
スペリエンスをなるたけ統一していこうという合言葉を持てればと思って
います。
2008/07/09 0:16 K. Ono <ono...@gmail.com>:
--
minahito (mina...@gmail.com)
K. Ono
> 抽象化はしていませんが、 ini 用に XCube_Config クラスは用意してあります。
> Root が site_config の読み込みに使うとして、
> 他のプログラムが ini ファイルを読み込む場合に使えるかもしれませんね。
>
> 今度コミットしておきますので、抽象化案ください。
XCube_ConfigFileというクラスがあったのですね。こんな感じできれば良いですね。
> 実は Controller という名前に最近抵抗がでてきたのですが、 Controller でも
> 大丈夫でしょうか。
>
> 0.9 では、ペリフェラルドライバの役割を ActionForm 、
> プリロード機構を ActionFilter、そして XCube_Controller と名前を Web の
> 類似の存在にマッピングしたのですが、かえって混乱を招いてしまったのでは
> ないかとちと反省しているところです。;;
本来はControllerでも良いとは思うのですが、タスクシステムを入れた時点から
メインのロジックがbuildTask()になったのでちょっとコントローラっぽく
ないなあとは感じていました。
>> タスクシステムを使用しないBaseはexecute()をオーバライドすれば
>
> これをやられてしまうと、
> 「PC に回ってもらうためにはタスクチェーンにつなぎさえすればよい」
> という感覚で、共通ランタイムメカニズムをアテにするマルチBASE対応
> プログラムが動かなくなっちゃいます。
>
> できれば空っぽでもいいのでタスクシステムはまわしてくれという感じに
> したいのですが……
タスクシステム必須といことは、例えば空でもレンダーオペレーションが
必ず存在するということですね。以前の投稿でレンダーオペレーションが
ない場合のことを書かれていたので、タスクシステムは必須とは限らない
のかと思っていました。
ただ、タスクシステム必須ということは、レガシーの方も改変が必要に
なってきますね。。
> というのがあったんですが、ファーストタスクをコントローラに見立てる
> のではなく、コントローラってものを明確に作って委譲しちゃうと当然そ
> れはなくなるので、このあたりがどうなのか反応をみてみたいです。
>
> （付け加えれば、XCube コアのレゾンデートル的に 1.0 で盛り込んだ固定
> 稼動のメカニズムに対する反応もまた得られてないのですが...
> 0.9風味も良いのですが、 1.0 案はマジでどうだったんでしょう）
すいません、この辺りちょっとよく分からないのですが、1.0案は
今CVSにあるものとはまたちょっと違うのでしょうか？^^;
> 問題は、タスクの粒度でコードを書いているときに、コントローラの下にある
> ユーザコンテキストを取得しにいくことに違和感があるやなしや、といったと
> ころかなと思います。
>
> これはフィーリングの問題だから弄ってみないと分からないか……
コントローラの下にあるというよりも、コントローラ実行時にパラメータとして
コントローラに渡されて、そのまま各タスクにも渡されていくという感じを
イメージしていました。
class XCube_Controller
{
function execute(&$context)
{
...
$rootTask->initializeAll($context);
...
}
}
class XCube_Task
{
....
function initializeAll(&$context)
{
for ($pTask =& $this; $pTask != null; $pTask =& $pTask->getNextTask()) {
if (!$pTask->mHasInitialized) {
$pTask->initialize($context);
$pTask->mHasInitialized = true;
}
}
}
function initialize(&$context){}
}
> えと、 Base を交換するという行為には、
> Legacy のようにまったく違う Base に交換することもあれば、
> Half-Life で Counter Strike を動かすように、メインシーケンスはほぼ同じで、
> 部分的に modify 状態になっているケースの２パターンがあるかと思います。
> （HD_Controller みたいに）
>
> onokazu さんが懸念されているのは前者かと思いますが、
> ユーザーさんが活用するのは主に後者だと思うんです。
>
> index.php に Base の初期化をハードコードしてしまうと、
> site_custom.ini.php だけで交換するということができなくなっています。
うーん、そうなんですか。。ただ、HD_Controllerも見てみましたが、
この程度の変更であったらdelegateやプリロード機構を使ってカスタマイズ
できるようにしたいですね^^;
minahito
> タスクシステム必須といことは、例えば空でもレンダーオペレーションが
> 必ず存在するということですね。以前の投稿でレンダーオペレーションが
> ない場合のことを書かれていたので、タスクシステムは必須とは限らない
> のかと思っていました。
Protector や、サービスの起動に関わる等、アウトプットのないタスクもあります。
たとえば SPAM 判定のサービスを提供するモジュールであれば、レンダーオペレー
ションは発行しないけど、組み込むならタスクシステムに繋げてね、という
スタンスになってくるかと思います。
ハイエンドユーザーであれば、
タスクシステムのタスクの調整と、
レンダーオペレーションのバインドだけで、コーディングに手を出さなくても、かなり
サイトが作れてしまうのではと考えているのですが、
（実際そういうクリエーションツールは実在する）
XOOPS Cube では、
このへんをエンドユーザーが直に触るような考え方はまだ先の話ですね。
> すいません、この辺りちょっとよく分からないのですが、1.0案は
> 今CVSにあるものとはまたちょっと違うのでしょうか？^^;
あれ
XCube_Controller って消してこそいませんが、
今使わないようになっていたと思ったのですが……
コミットしていないのかもしれません。
確認してみます。
> コントローラの下にあるというよりも、コントローラ実行時にパラメータとして
> コントローラに渡されて、そのまま各タスクにも渡されていくという感じを
> イメージしていました。
XCube_Root からたどれるところの下に入れておかないと、デリゲートなどで、
コンテキストが渡ってないとアクセスできなくなってしまうので、遊びの幅は
確実に縮まると思います。
実際に XOOPS Cube で動くプログラムで、コンテキストスイッチはまず起きない
と思うので、
（一部仮想サービス絡みでありますが）
「コンテキストを渡してない以上、その流れの中ではコンテキストにアクセスしては
ならない」
みたいな "クール" なことをやってしまうと、
XOOPS Cube 活用の場ではウケは悪いと思います。
> うーん、そうなんですか。。ただ、HD_Controllerも見てみましたが、
> この程度の変更であったらdelegateやプリロード機構を使ってカスタマイズ
> できるようにしたいですね^^;
僕はプリロードは減らしたい……
ディストリくらいの単位であれば、
メソッドの抽象化はできるだけ、
デリゲートを使わずにオーバーライドで畳み込む方針でやってほしいです。
結局プリロードの抜き差しはエンドユーザーの作業になるので、
デフォルトで色々デリゲートが刺さっている状態からスタートしたり、
デリゲートを突き刺して HD_Controller の状態を作ってくださいというのは、
かなりハードだと思います。
プリロードは、
アプリ開発やカスタマイズ、そのアドバイス、ノウハウ交換等に
手間暇かけられないフリーウェア活動に効果を持つもので、
ちゃんとコードを畳み込んで Foo_Controller のようなクラスを作って
頒布する余力があるのであれば、その差分の量に関わらず、オーバー
ライドでいってほしいなぁと思います。
ですから、プリロードだけでまったく動作の違うものを作り出すケース
も上記の事情であればアリでしょう。
しかしそれを推奨するとか、それしかできなくするというのは、
できれば避けたほうが無難かと思っとります。
2008/07/12 12:35 K. Ono <ono...@gmail.com>:
--
minahito (mina...@gmail.com)
K. Ono
> Protector や、サービスの起動に関わる等、アウトプットのないタスクもあります。
> たとえば SPAM 判定のサービスを提供するモジュールであれば、レンダーオペレー
> ションは発行しないけど、組み込むならタスクシステムに繋げてね、という
> スタンスになってくるかと思います。
そうですか、そうするとやはりレガシーにも何らかの対応が必要になりますね。
>> すいません、この辺りちょっとよく分からないのですが、1.0案は
>> 今CVSにあるものとはまたちょっと違うのでしょうか？^^;
>
> あれ
> XCube_Controller って消してこそいませんが、
> 今使わないようになっていたと思ったのですが……
いえ、0.9案と1.0案が具体的にどのように違うのがこちらで把握できていません
でしたので。。何か簡単な比較表みたいなものはありますでしょうか。
>> コントローラの下にあるというよりも、コントローラ実行時にパラメータとして
>> コントローラに渡されて、そのまま各タスクにも渡されていくという感じを
>> イメージしていました。
>
> XCube_Root からたどれるところの下に入れておかないと、デリゲートなどで、
> コンテキストが渡ってないとアクセスできなくなってしまうので、遊びの幅は
> 確実に縮まると思います。
おそらくデリゲート等はタスクから呼び出されるものだと思いますので、タスクに
コンテキストが渡されていれば、そのままデリゲートに渡すということも問題
ないのではと思います。いちいちパラメータとして渡さなければいけない
というのは確かに面倒臭いですが。。
> 実際に XOOPS Cube で動くプログラムで、コンテキストスイッチはまず起きない
> と思うので、
> （一部仮想サービス絡みでありますが）
確かに仮想サービスの部分でコンテキストのリクエストを入れ替えたりしていますね。
このような状況は将来的には結構でてくるんじゃないかなーと思うのですが、
そうでもないのでしょうか。
例えば、モジュールAからモジュールBを呼び出してモジュールBの描画結果を
モジュールAで使用したり。。その呼び出す際には特定のリクエスト値や
ユーザ権限を渡さなくてはいけなかったりした場合、新たにコンテキストを
発行して渡せないと仮想サービスでやっているような裏技が必要になってきてしまいますね。。
> 僕はプリロードは減らしたい……
> ディストリくらいの単位であれば、
> メソッドの抽象化はできるだけ、
> デリゲートを使わずにオーバーライドで畳み込む方針でやってほしいです。
それも確かにありますね。。いずれにしてもHD_Controllerでやっている改変は
コントローラがない1.0案（？）では起きることはなさそうですね。redirectの
改変等はなんらかのビュークラスやレンダーシステムのオーバーライドになるでしょうし。。
K. Ono
> まずは、
>
> ・各種サブシステムを作る
> ・各種サブシステムを保持する
>
> ですが、これはXCube_Rootの本来の役割だと思いますので、このままで。
この件ですが、役割としてはこれで問題ないと思うのですが、例えば独自の
ライブラリがあって、それをRoot経由で使えるようにしたいということが
これからどんどん出てくるかと思います。
そこで、現在では利用可能なサブシステムが全てハードコードされていて、特定の
サブシステムしか生成／取得できませんが、これをもう少し汎用的にできないかと
思うのですがいかがでしょうか。XCube_Serviceを使えという意見も出てくるかも
しれませんが、やはり独自のライブラリをネイティブに使用できることに
こしたことはないと思います。
イメージ的には下記のような感じになれば良いなと思っています。
$root =& XCube_Root::getSingleton();
$root->loadSiteConfig($config);
$container =& $root->getContainer();
// データベースコネクションオブジェクトの情報を「DB」コンポーネントとして登録
$container->registerComponent('DB', array('scheme' => 'mysql', 'host'
=> 'localhost', 'database' => 'database', 'user' => 'root', 'pass' =>
''));
// デフォルトの「DB」コンポーネントを取得
$db =& $container->getComponent('DB');
// デフォルトとは接続先のデータベースだけ異なる「DB」コンポーネントを取得
$db2 =& $container->getComponent('DB', array('database' => 'database2'));
のように、通常のRegistryとしてだけではなく、Factory的なこともできれば良いなと。。
また、下記のように各コンポーネントの依存性も解決することができればもっと便利かなと思います。
// 「DB」コンポーネントに依存するモデルオブジェクトの情報を「Model」コンポーネントとして登録
$container->registerComponent('Model', array('modelDirectory' =>
dirname(__FILE__) . '/models', 'DB' => null));
// デフォルトの「DB」コンポーネントを使用する「Model」コンポーネントを取得
$model =& $container->getComponent('Model');
// 別データベースへと接続する「DB」コンポーネントを使用する「Model」コンポーネントを取得
$model2 =& $container->getComponent('Model', array('DB' => &$db2));
もちろん、上記の登録作業の箇所（$container->registerComponent()）については、
$rootが最初に設定ファイルを読み込む際等に自動的に行われるのが好ましいと思います。
K. Ono
先の投稿内容を見返したら、registerComponent()の時にファイル名やクラス名等の情報が渡されて
いませんでした。。それでもイメージとしては分かっていただけたのではと思います。
似たようなものは下記で作っているのですが、先の例とは名称が違う（ComponentがServiceであったり等）
ので分かりにくいかもしれません。もし良ければ下記内容のものを少し改変してコアにコミットできれば
と思っています。
http://sabai.svn.sourceforge.net/viewvc/sabai/trunk/Sabai/Sabai/Service/
minahito
先にこちらにレスを...
> いえ、0.9案と1.0案が具体的にどのように違うのがこちらで把握できていません
> でしたので。。何か簡単な比較表みたいなものはありますでしょうか。
比較表は作っていませんが、追加機能と廃止機能はどこかにまとめてあった
ので探しておきます。
といっても廃止になるのはコントローラ程度で、 Legacy は 0.9 を使い続ける
というプランのはずです。これは掲示板に書いたはず……探しておきます。
>> XCube_Root からたどれるところの下に入れておかないと、デリゲートなどで、
>> コンテキストが渡ってないとアクセスできなくなってしまうので、遊びの幅は
>> 確実に縮まると思います。
>
> おそらくデリゲート等はタスクから呼び出されるものだと思いますので、タスクに
> コンテキストが渡されていれば、そのままデリゲートに渡すということも問題
> ないのではと思います。いちいちパラメータとして渡さなければいけない
> というのは確かに面倒臭いですが。。
すみません、僕の書き方が悪くて言いたい事が伝わりませんでした。
もう一度表現を改めて書き直しますと、
デリゲートでコンテキストが渡っていなくても、コンテキストを調べたい場面が
XOOPS Cube の使われ方ではかなりあります。
たとえば XOOPS2 ではフックという概念がなかったので、
言語定義ファイルの php にコードを書いて、そこでコアのシーケンスに割り込む
というテクニックがありました。
XOOPS のようなアプリケーションでは、ユーザーサイドにおける創造的な使用
方法に対して、少し緩めに考える必要があります。これは何も XOOPS に限った
話ではなく、ツクールのようなツールでも求められることです。
コンテキストのように何か処理を加えたいときに調べたいという要望が高いと思
われる情報を、「パラメータに加えないと調べられません」という考え方を採用
することが、ユーザーにとって遊びの幅を広げるのか、狭めるのか、ということ
が言いたかったのです。
僕は狭めると思うので、このやり方には反対です。
僕たちはプロの Web プログラマではありませんし、
プロのための業務用アプリケーションを開発している訳ではありません。
onokazu さんの案は現場で集団でフルスクラッチアプリケーション開発を行って
いるときに、バグの頻度を減らす設計だと思います。
しかし、それが XOOPS Cube の想定している用途でしょうか。
XOOPS2 でいえば特定の局面でなければ $xoopsUser が引けないというような考
え方ですよね？
これはかなり痛いと思います。
多分何らかの回避策がユーザー側でとられることになるでしょう
（プリロードを使ってグローバル変数にポインタを掴ませるとか）
また会社で開発している訳ではないので、
「このデリゲートの第一パラメータにコンテキストを加えてよ」
「あーいいよー」
ということもできません。
（第一シグニチャが変わってしまう）
> 例えば、モジュールAからモジュールBを呼び出してモジュールBの描画結果を
> モジュールAで使用したり。。
基本的に XOOPS ってモジュールAとモジュールBはバラバラに作られていて、
それをユーザーがチョイスして使うという手順で活用されるものではないでしょ
うか？ それを連携させるために仮想サービスとデリゲートがあるわけで……
特に描画結果の活用という部分が、あんまり活用方法として想像がついていませ
ん。かなり密ですよね？
この用途というのは、業務の開発ではよくあって、最近のフレームワークはそう
いった使い方に対応した機能を積んでいるというのは聞いたことがあります。
しかし、 XOOPS でそれに対応するために、コンテキストをルート下から落とす
というのはプライオリティが違う（XOOPS的でない）ような気がしてなりません。
> ユーザ権限を渡さなくてはいけなかったりした場合、新たにコンテキストを
> 発行して渡せないと仮想サービスでやっているような裏技が必要になってきてしまいますね。。
まぁ個人的には、仮想サービスでやってる「裏技」こそが、
本来で言うところのコンテキストスイッチに近いと思ってるんで
そこまで気にしてなかったりするんですが (^^;
このへんはみんなの声を聞きたいところです。
コンテキストを渡す場面でなければコンテキストを調べられないでいーよとか、
モジュールの描画結果を直接使うような機能は XOOPS 的に必須だよとかとか、
（その場合汎用レンダーシーケンス自体がふっとびますけど）
2008/07/18 14:38 K. Ono <ono...@gmail.com>:
--
minahito (mina...@gmail.com)
minahito
途中で送ってしまった;;
> このへんはみんなの声を聞きたいところです。
> コンテキストを渡す場面でなければコンテキストを調べられないでいーよとか、
> モジュールの描画結果を直接使うような機能は XOOPS 的に必須だよとかとか、
> （その場合汎用レンダーシーケンス自体がふっとびますけど）
（続けて）
いうことであれば、ルート下からコンテキストを外す事に何の異論もありません。
# （↑）この一文を最後に書くのをわすれとった。
2008/07/20 14:04 minahito <mina...@gmail.com>:
--
minahito (mina...@gmail.com)
minahito
>> いえ、0.9案と1.0案が具体的にどのように違うのがこちらで把握できていません
>> でしたので。。何か簡単な比較表みたいなものはありますでしょうか。
>
> 比較表は作っていませんが、追加機能と廃止機能はどこかにまとめてあった
> ので探しておきます。
>
> といっても廃止になるのはコントローラ程度で、 Legacy は 0.9 を使い続ける
> というプランのはずです。これは掲示板に書いたはず……探しておきます。
ありました。
onokazu さんに見せるには恥ずかしいですが（爆）
http://sourceforge.net/forum/message.php?msg_id=4583406
英語がイモすぎてわかんねんだよ！！
みたいな部分は聞いてくださいませ。 m(__)m > onokazu さん, ALL
今の Legacy は無理に変更せずに 0.9 をキープさせるほうが妥当だろうという
話も出てると思います。
--
minahito (mina...@gmail.com)
K. Ono
> コンテキストのように何か処理を加えたいときに調べたいという要望が高いと思
> われる情報を、「パラメータに加えないと調べられません」という考え方を採用
> することが、ユーザーにとって遊びの幅を広げるのか、狭めるのか、ということ
> が言いたかったのです。
>
> 僕は狭めると思うので、このやり方には反対です。
幅が狭まるかどうかはちょっと分かりませんが、デリゲートの例で少し書いてみます。
デリゲートは、デリゲートを行う側がある特定の作業をデリゲートしたい場合に
発行すると思うんです。その時にデリゲートの際に必要な情報は全てパラメータとして
渡すというのを慣例にしないと、デリゲートの発行側がデリゲート実行側を制御できなく
なってきたりはしないでしょうか。
例えばデリゲートのシグネチャ機構を使っていくら型安全にしても、rootがグローバルに
アクセス可能であるがために、rootから取得してきた別型のオブジェクトを使用してしまう。。
これが以前にもrootのグローバル化が危険ではないかと書いた理由でもあります。
コンテキスト情報にアクセスさせたいのであれば、コンテキストをパラメータとして
渡せば良いし、コンテキスト情報にアクセスさせたくないのであれば渡さなければ
良いので、グローバルにアクセスできる時よりも逆に実装の幅が広がる（グローバル
だとアクセスを制限することができないため）のではないかと思います。
> また会社で開発している訳ではないので、
>
> 「このデリゲートの第一パラメータにコンテキストを加えてよ」
> 「あーいいよー」
>
> ということもできません。
> （第一シグニチャが変わってしまう）
これはデリゲートを発行している側の開発者にお願いすれば良いだけの気もしますが。。
逆に業務で開発しているものの方がこういった変更は難しいのではないかと思います。
この辺り、実際のところどうなるかはちょっと分かりませんが。。
また、パラメータとして渡すことでグローバルへの依存を防ぐことになりますので、
例えばroot側で何らかの変更があった場合に、デリゲート実行側はその影響を
受けない（渡されたパラメータに対してのみ依存しているため）という利点も
あるかと思います。
> 基本的に XOOPS ってモジュールAとモジュールBはバラバラに作られていて、
> それをユーザーがチョイスして使うという手順で活用されるものではないでしょ
> うか？
このモジュールの考え方はレガシーのものではないでしょうか？モジュールの
実装方法はそれを実装するBASEによって違ってくるので、それは一概には
言えないのではないかと思うのですが、どうなんでしょうか。例えばdrupal
なんかはモジュール同士の連携がかなり柔軟にできるようになっていますね。
> このへんはみんなの声を聞きたいところです。
> コンテキストを渡す場面でなければコンテキストを調べられないでいーよとか、
> モジュールの描画結果を直接使うような機能は XOOPS 的に必須だよとかとか、
確かに別モジュールの描画結果を使用するという機会はあまりないかもしれません。
これはあくまでも例として挙げただけですので^^;
> （その場合汎用レンダーシーケンス自体がふっとびますけど）
そういうことはないと思います。呼び出されるモジュール側も独自の
コンテキスト下で、通常通りレンダーシーケンスが実行されると思いますので。
そのレンダー結果を、呼び出したモジュール側のレンダーシーケンスで使用
するというだけのことですので。あくまでも想像ですが。。^^;
minahito
> 幅が狭まるかどうかはちょっと分かりませんが、デリゲートの例で少し書いてみます。
>
> デリゲートは、デリゲートを行う側がある特定の作業をデリゲートしたい場合に
> 発行すると思うんです。その時にデリゲートの際に必要な情報は全てパラメータとして
> 渡すというのを慣例にしないと、デリゲートの発行側がデリゲート実行側を制御できなく
> なってきたりはしないでしょうか。
デリゲートの発行側がデリゲートの実行側を制御する、というのがよくわからない
のです。
よく分からない、というのは、シチュエーション的にピンと来ないということです。
もし、呼び出し元が呼び出し側を制御する必要があるなら、その状況で、デリゲー
ト（単純なコールバック）を使うこと自体がミスチョイスであり、別の実装方法を
取る必要があるのではないでしょうか。
> コンテキスト情報にアクセスさせたいのであれば、コンテキストをパラメータとして
> 渡せば良いし、コンテキスト情報にアクセスさせたくないのであれば渡さなければ
> 良いので、グローバルにアクセスできる時よりも逆に実装の幅が広がる（グローバル
> だとアクセスを制限することができないため）のではないかと思います。
うーん、実装の幅が広がりますか？
僕は安全性と引き換えに可能性が落ちるという印象しか受けません。
ずっと繰り返し同じ感想を書いて申し訳ないのですが、
とにかく、やれることが少なくなる、減ってしまう！という印象なんです。
で、これまでのプリロードの楽しまれ方を見てると、
言葉は悪いですが改悪と受け取られるんじゃないかと思います。
>> また会社で開発している訳ではないので、
>>
>> 「このデリゲートの第一パラメータにコンテキストを加えてよ」
>> 「あーいいよー」
>>
>> ということもできません。
>> （第一シグニチャが変わってしまう）
>
> これはデリゲートを発行している側の開発者にお願いすれば良いだけの気もしますが。。
オーバーロード定義ができないんですから、
デリゲートのシグニチャを変える（パラメータを増やす）と、既存のデリゲートに登録
している関数の動作が変わる可能性があります。
それをフリーソフトウェアのようにばらばらのリリースタイミングで動いていて、
しかもユーザーは各素材を組み合わせて独自にサイトを作っている。
そこで、デリゲートの仕様が変わるというのはかなり重大な変更であり、とても
気軽にできる話ではないと思うのですが。
> 逆に業務で開発しているものの方がこういった変更は難しいのではないかと思います。
> この辺り、実際のところどうなるかはちょっと分かりませんが。。
業務で開発している場合は、
コールバックの型が変われば関係者に一報するだけで済むので簡単に変更できますよ。
僕の仕事の場合、コンパイル通らなくなるので一報した上で該当部を全部変更してコミッ
トすることが多いですけど。
少なくとも自分の仕事ではそうです。
そして仕事だからこそ、担当のプログラマに「ちょっとパラメータ増やしてよ～」と
頼んでも、全然まわりに迷惑かけずにやれます。登場人物の数が知れてるし、同僚で
すから。
>> 基本的に XOOPS ってモジュールAとモジュールBはバラバラに作られていて、
>> それをユーザーがチョイスして使うという手順で活用されるものではないでしょ
>> うか？
>
> このモジュールの考え方はレガシーのものではないでしょうか？モジュールの
> 実装方法はそれを実装するBASEによって違ってくるので、それは一概には
> 言えないのではないかと思うのですが、どうなんでしょうか。
いろんなところで書いていますが、
XOOPS Cube の基本的な考えは、
コアがあってそこに BASE パッケージを適用、
追加プログラム素材を入れて、環境設定でカバーできない範囲をプリロードで
調整。最後にテーマを適用して完成！という XOOPS2 をちょっと多段階化した
ものが基本的なモデルになっていて、それを支援するものがコアという全体像
になっています。
それで僕としては、モジュールAとモジュールBが直接ご指名連携するという
のはかなりピンとこなかったし、ユーザーがどう設定してそれを活用するのか、
そのためにコンテキストをルート下から落として本当に楽しい事になるのか？
というのが分かんなかったりする訳です。
# ぱっと思いつくのは業者さんがモジュールを開発するときに
# そういう設計だったら便利なのかもな、という感じです
なので先も書きましたが、このへんはいろんな人の意見を聞いてみたいです。
>> （その場合汎用レンダーシーケンス自体がふっとびますけど）
>
> そういうことはないと思います。呼び出されるモジュール側も独自の
> コンテキスト下で、通常通りレンダーシーケンスが実行されると思いますので。
> そのレンダー結果を、呼び出したモジュール側のレンダーシーケンスで使用
> するというだけのことですので。あくまでも想像ですが。。^^;
呼び出したコンテキスト下でレンダーシーケンスが実行される...？
レンダーシーケンスは全体で１回しか実行する事ができないし、
あるタスクが他タスクの描画結果をコード上で手に入れる方法はないから
僕は汎用レンダーシーケンスという考え方自体がなくなると書きました。
もちろん前のレンダリングの結果にアクセスする形での合成はできます。
（そのための汎用レンダーシーケンスですから）
ただこれは空間的にはモジュールAがモジュールBの描画結果にアクセスしている
訳ではありません。
たとえば Sample の左タスクのコード内で右タスクの描画結果をコード上で入手す
ることはできないはずです。
できるできない以前に僕としては（↓）に尽きるんですけど (^^;
> このへんはみんなの声を聞きたいところです。
> コンテキストを渡す場面でなければコンテキストを調べられないでいーよとか、
> モジュールの描画結果を直接使うような機能は XOOPS 的に必須だよとかとか、
すみません、本当にちょっとピンとこないんですよ。
ピンとこないという表現はすごく失礼なんですけど、
XOOPS の世界観上で用途が思いつかないというか……
もちろん、プログラムがそれらしくなって、
プロの Web プログラマに多少なりとも訴求できるとか、そういう効果があるよな
とかいうのは分かるんですが、
トレードオフになるものがあるのが痛い……
（しかもそれは今一番楽しまれている事のひとつだと認識しています）
そういうトレードオフがなければ、どんどん積めば良いと思うんですが。。。
感覚としては、
掲示板上でわいわいやってるユーザーに背を向けて、
業者さんのほうを向くような判断のように感じられるんですよ。
（ピンと来てないからそう感じるのかもしれない）
業者さんのほうを向くのが問題だと言ってるのではなくて、
そっち向くとユーザーに背を向けることになるのが構図としてむちゃくちゃ気になる。
だから、ここは機能的にどうとか、設計的にどうとかいう話ではなく、
全体の意見で聞いて決めていく必要があると思うのですが、
onokazu さんはどうですか？
onokazu さんのコンテキストをルート下から落とすアイデアは、
それくらいインパクトのでかいもので、このマンツー議論だけで決定するには重すぎる
と思います。
僕は怖いです。
# といってもこのトピックも現時点では特に注目されていないし
# 読まれてもいないと思うので、一旦保留して、
# どっかでスナップショットをアーカイブするか、ドキュメントを書く
# 際に２つのアイデアを書いて（文字でいい）反応を求めるという手順でどうでしょう。
2008/07/20 21:42 K. Ono <ono...@gmail.com>:
--
minahito (mina...@gmail.com)
gusagi
> # といってもこのトピックも現時点では特に注目されていないし
> # 読まれてもいないと思うので、一旦保留して、
すみません、議題が難しかったこともあり、スレッドを追ってはいても、
発言出来ていませんでした。
ただ、気になった部分があるので、ピンポイントでレスさせて下さい。
>> これはデリゲートを発行している側の開発者にお願いすれば良いだけの気もしますが。。
>
> オーバーロード定義ができないんですから、
> デリゲートのシグニチャを変える（パラメータを増やす）と、既存のデリゲートに登録
> している関数の動作が変わる可能性があります。
>
> それをフリーソフトウェアのようにばらばらのリリースタイミングで動いていて、
> しかもユーザーは各素材を組み合わせて独自にサイトを作っている。
> そこで、デリゲートの仕様が変わるというのはかなり重大な変更であり、とても
> 気軽にできる話ではないと思うのですが。
実際にインターフェースが変わることになると、現時点で動いているプリロードが
使えなくなる可能性が高いですよね。
今後のXCのモジュールなどでX2時代との互換性が無くなることは問題ないかも
知れませんが、XCL2.1との互換性が無くなったりするのは、影響が大きくありませんか？
X2からXCLへの移行で、下位互換性を気にする人は多いと思いますが、
同じことがXCL2.1と2.2（？）でモジュール枠より大きな範囲で
互換性が無くなることは大きなデメリットだと思います。
2008/07/21 1:41 minahito <mina...@gmail.com>:
minahito
gusagi さんレスポンスありがとうございます。
> 実際にインターフェースが変わることになると、現時点で動いているプリロードが
> 使えなくなる可能性が高いですよね。
> 今後のXCのモジュールなどでX2時代との互換性が無くなることは問題ないかも
> 知れませんが、XCL2.1との互換性が無くなったりするのは、影響が大きくありませんか？
2.1 -> 次バージョン一回こっきりで発生する動作保証不安なら、
まだ乗り越えられるかもしれません。
僕が気になったのは、
onokazu さんが主張されている
「デリゲート毎に、コンテキストが不足だったら開発者に頼んでパラメータに追加して
もらうだけで済む」
という状況のほうで、
これはある開発者がある人のお願いでパラメータを弄る毎に、既存のそれを利用する
プリロード等の動作保証がなくなるので、ケースとしては不定期に多発する性質の
ものに思えたので、不安になったのです。
> すみません、議題が難しかったこともあり、スレッドを追ってはいても、
> 発言出来ていませんでした。
自分なりに分かりやすい例えを考えてみたのですが、
たとえばこれが RPG ツ○ールだとすると、
1) minahito 案（従来型）
スクリプトはいつでも「プレイヤーのステータス」を調べることができる。
2) onokazu 案（改善型）
スクリプトが「プレイヤーのステータス」を調べられるかどうかは、呼び出し元
によって異なる。
ということになると思います。
「てつのつるぎ」で攻撃する処理を、
ユーザーが割り込んでプログラマブルに自由に処理できるとしましょう。
attack($攻撃力, $敵のインスタンス);
1) なら、
プレイヤーのHPが１０以下なら攻撃力が２倍になるとか、
プレイヤーの性別が女性なら魔法攻撃になるとか、
そういうユニークな攻撃を記述することができます。
2) なら、
呼び出し元が「RPGを作る人がこの処理でプレイヤーを調べる必要などない」
と判断していれば、プレイヤーのステータスにアクセスできません。
従って、淡々と敵の防御力と武器の攻撃力を使って計算する事しかできない
かもしれません。
開発者にお願いしてアクセスできるパラメータを増やしてもらうことはできます。
引き換えにこれまで動いていたスクリプトの動作保証がなくなります。
で、ずっと 1) のノリで来ていて実際に使われてきたのに、
1) → 2) にするのはデグレードに見えるだろうと思う訳です。
こういうエンジンばっかり実際作ってきた身としては、
こういうものは、
1) の応用例に意味があるかどうかに関係なく 1) のようであったほうが喜ばれますし、
少なくともモノホンの RPG ツ○ールで 1) → 2) のような仕様変更があったら、
ユーザー怒ると思うんですよ。
自由度下がってますもん。
onokazu さんが
「1) の仕様では、呼び出し元が呼び出し先の制御ができない」
と書かれていた事に対するレスとして、
「そもそも制御する必要はない。制御したいならデリゲートを使うべきじゃない」
と返信したのは、僕が上のような考えを持っているからです。
「武器攻撃は敵のステータスと、計算済みの攻撃力があればいいだろ。常考」
みたいなのは、ちょっと違うかなと……
できるだけ色々調べられたほうが面白いと思うんです。
RPG ツ○ールだと、基本的にどのようなシーンでも使えるコマンドは全部使える
ので……
# 戦闘モードの戦闘中に、マップを書き替える事とかさえできる。
# 「てつのつるぎ」で攻撃したら、川に橋が架かるとか。
# 戦闘シーンなんだから、マップにアクセスできるのがそもそもおかしいと考えて
# そのアクセス経路を全部絶つ、みたいな考え方は、
# プログラム的には立派ですけど、おもちゃとしてどーなのよ、という意見です。
ただ、実際にデリゲートで遊んでるみなさんが 2) で全然OKというのであれば、
僕も反対する理由はまったく無いので、
そのへんがちょっと知りたくて……
2008/07/21 2:03 gusagi <gus...@gmail.com>:
--
minahito (mina...@gmail.com)
K. Ono
> デリゲートの発行側がデリゲートの実行側を制御する、というのがよくわからない
> のです。
> よく分からない、というのは、シチュエーション的にピンと来ないということです。
制御するというか、デリゲートを発行する側はそれなりの意図があって、デリゲートを
発行すると思うんです。そして、その意図を実現してくれるためにパラメータに必要な
情報を提供する。それなのに、グローバルにアクセス可能な情報があると、デリゲート
を発行した人の意図にそぐわないことをやられてしまう可能性があるという意味です。
> 僕は安全性と引き換えに可能性が落ちるという印象しか受けません。
> ずっと繰り返し同じ感想を書いて申し訳ないのですが、
> とにかく、やれることが少なくなる、減ってしまう！という印象なんです。
うーん、先にも書きましたが、minahitoさんのようにコンテキストへとアクセス
させたいのであれば、コンテキストを渡せば良いだけなんです。コンテキストへと
アクセスさせたくないのであれば、渡さなければ良い。もしもグローバルで
いつでもアクセス可能な場合は、後者のようにアクセスさせないようにすることは
できない。そういう意味では、実装の機会が失われているのではないかということです。
例えば、
> attack($攻撃力, $敵のインスタンス);
>
> 1) なら、
> プレイヤーのHPが１０以下なら攻撃力が２倍になるとか、
の件ですが、プレイヤーによっての攻撃力の計算はこっちでやるから、
デリゲート側でそんなことは絶対にしてくれないで欲しい、という
場合にはどうするのでしょうか。
ま、それでも大抵の場合はコンテキストを渡す必要があると思うんです。要は、
渡す渡さないが重要なのではなくて、少なくともデリゲートレベルでは
渡されたパラメータのみを使用して何でもやってくれというスタンスでないと、
好き勝手にグローバルなアクセスばかりになってしまったりしやしないかと。。
そういう意味ではコンテキストではなく、シングルトンであるルートを渡して
いく（ルートの非シングルトン化）方が重要だったかもしれない。。(^^;
minahito
> プレイヤーによっての攻撃力の計算はこっちでやるから、
> デリゲート側でそんなことは絶対にしてくれないで欲しい、という
> 場合にはどうするのでしょうか。
さっきから同じ事を何回も繰り返しているような気がするのですが、
これは一体全体どういうケースなのでしょうか。
RPG ツ○ールのようなソフトで、そういうスタンスを利用側に押し付ける
こと自体が僕には想像できないのです。
> うーん、先にも書きましたが、minahitoさんのようにコンテキストへとアクセス
> させたいのであれば、コンテキストを渡せば良いだけなんです。
この話は、
「minahito がコンテキストへアクセス"させたい"」じゃなくて、
「利用側がコンテキストにアクセス"したい"」なんです。
それがデリゲートの発行元に握り込まれるのが凄く嫌なんです。
アプリケーションとしてはいいのかもしれないけど、
XOOPS としてどうなんだという感じ。
そのために「利用者側が誰かにお願いする」という構図も凄くまずいと思う。
うまく回っていくとは思えない。
> デリゲートを発行した人の意図にそぐわないことをやられてしまう
> 可能性があるという意味です。
「意図にそぐわない事をやられてしまう」という表現がどうも気になります。
ものすごくネガティブな事態だと考えているということですよね。
ここが僕と onokazu さんの一番の違いのようです。
> そういう意味ではコンテキストではなく、シングルトンであるルートを渡して
> いく（ルートの非シングルトン化）方が重要だったかもしれない。。(^^;
いやいやいや、僕はアリエナイと思います。
使ってて面白くないですって……
うーん……
何度も同じ事を書いて恐縮ですが、
XOOPS は、「なるほど、これを逆手に取ってこうしたか」みたいなのが
一番おもしろいと思います。
結局そういったことが RPG ツ○ールや Mod のような活動の魅力の最たるものだと
思います。
> もしもグローバルでいつでもアクセス可能な場合は、後者のようにアクセスさせ
> ないようにすることはできない。そういう意味では、実装の機会が失われている
> のではないかということです。
「実装の機会が失われている」というか、
「禁止させる行為ができない」「呼び出し元が呼び出し先を制御下におけない」と
いうことですよね。
2008/07/21 8:21 K. Ono <ono...@gmail.com>:
--
minahito (mina...@gmail.com)
氷川霧霞
minahito です。
> プレイヤーによっての攻撃力の計算はこっちでやるから、
> デリゲート側でそんなことは絶対にしてくれないで欲しい、という
> 場合にはどうするのでしょうか。
さっきから同じ事を何回も繰り返しているような気がするのですが、
これは一体全体どういうケースなのでしょうか。
RPG ツ○ールのようなソフトで、そういうスタンスを利用側に押し付ける
こと自体が僕には想像できないのです。
この部分はシステムのあり方としては minahito さんに賛成です。
デリゲート先の処理を書き換える側で責任を持ってやりたいよう
にやれるほうが良いと思います。
どうせデリゲート側で制限しようとしても、最終的にはコード直接
書き換えて無理矢理できるようにしちゃう訳ですし、それより
せっかくのデリゲートで対応できた方がいいです。
ただ、
>例えばデリゲートのシグネチャ機構を使っていくら型安全にしても
>アクセス可能であるがために、rootから取得してきた別型の
>オブジェクトを使用してしまう。。
>これが以前にもrootのグローバル化が危険ではないかと書いた
>理由でもあります。
このあたりの懸念が現実にどれほど深刻なものになりうるのか、
評価できない状態での感想ではあります（十分理解できていない
のは他にもあちこちに）。
K. Ono
うーん。。XOOPS的でないので面白くないと言われてしまうと、こちらとしても
どのように返して良いのか分からない。。^^;
僕としては、XOOPSの曖昧さや何でもあり的な点が、XOOPSが熟練した開発者達
より敬遠される一因でもあるのではないかと思っていたのですが。。
とりあえず、この話は一度置いておいて、もう少し開発が進んでから再度
考えてみたいと思います。もしかすると、こちらで捉えていた、汎用的な
開発フレームワークとしてのコアという概念が強すぎたのかもしれません。
龍司
2008/07/21 19:05 K. Ono <ono...@gmail.com>:
> 僕としては、XOOPSの曖昧さや何でもあり的な点が、XOOPSが熟練した開発者達
> より敬遠される一因でもあるのではないかと思っていたのですが。。
周囲のプログラマの話を聞いていると、その点よりも、
cubsonベースのlegacyのコードにあわせなきゃいけないって思われてて、「この書き方はイヤ」とか「デリゲートのせいで、処理が全然追えないっ」とかの方が、敬遠要因としては大きいんじゃないかと思ってます。
なので、最近は、legacyのコードにあわせなくていいんだよってことを良く話してます。
K. Ono
>周囲のプログラマの話を聞いていると、その点よりも、
>cubsonベースのlegacyのコードにあわせなきゃいけないって思われてて、「この書
>き方はイヤ」とか「デリゲートのせいで、処理が全然追えないっ」とかの方が、敬
>遠要因としては大きいんじゃないかと思ってます。
>
>なので、最近は、legacyのコードにあわせなくていいんだよってことを良く話して
>ます。
確かにstruts似のcubsonスタイルは今となっては少しとっつきにくいかも
しれないですね。
デリゲートに関しては、以前にも書きましたが、各デリゲートには必ず
ユニークな名称がついて、デリゲートの呼び出しは必ずデリゲートマネジャー
経由でそのデリゲート名を使って行うことでかなり見通しが良くなる気が
するのですが、この案もまた×なんでしょうかね。。