* Xhwlay_Hook、途中まで作ったけど・・・。うーん、やっぱ作り直し。

全部staticなのが、ちょっと、ね・・・。一番いただけないと気づいたのは、HOOKポイントの中からHook操作を行う場面を想定した場合。今の形だと、Hook操作用のstaticメソッドは全て、HOOK名を指定する。

→Hookポイント自身が、どこで使われるか把握していないといけない。

・・・う～～ん・・・これは、さすがに、ペケ。HookポイントはどのHOOKに設定されるか分からないのが基本。まあ確かに、HOOKの性質からどのPOINTにHOOKされるのかは限定されるのは確かだけど、名前までHOOKポイントの中で知っていなければならないのは、硬直が過ぎる。
・・・ああ・・・HOOK名をHOOKのI/Fに渡しても、良いのか。いや、駄目かも。

ただ、Xhwlay_HookはXhwlay_Varとは大分性質が異なる。かなり能動的なクラスであり、インスタンス化して使用するとしても不自然ではない。
getInstanceの内部でFactoryContainer化することは十分に可能だし。
Xhwlay_Runnerレベルで使用するのと、その上のApplication layerで使用するのを分離するのも、インスタンスを分けることでより、間違いを減らすことが可能だ。
つまりXhwlay_Hookにおいては、インスタンス化し、FactoryContainerに対応させることで、インスタンスを分離することでHOOKのnamespace or domain を分離することが可能になる。

ぶっちゃけたところ、Xhwlay_Varはメソッド数も大したこと無いので、各メソッドの冒頭で Xhwlway_Var::getInstance()(protected) を呼ぶのはさほどの苦ではなかった。また、かなり単純なクラスで、使用用途も決まっていて、拡張するような代物でもないため、クラスの拡張を考慮する必要は無かった。

けど、HOOKとなるとねえ・・・。Application Layerで独自に拡張したい場合も十分あるだろうし・・・。という訳。まあ、実行中のHOOKを覚えておくHOOK Stackはこれで無用にはなる。あと、callbackやresultの扱いも、[$hook]が削り取られる分シンプルで安全になるし。

あと、すんごい迷っているのがresultの取り扱い。破壊的操作にするのか(pop)、非破壊的（＝接触）操作にするのか(copy on writeによるコピー渡し)、迷ってる。あと、HOOKポイントがnullを渡したときの取り扱いがチョービミョー。値を返さないHOOKが混じっていたことによるnullなのか、有意であるnullなのか。それにより、resultスタックにpushするのか、しないのかがチョービミョー。どうしよう？

・・・という風に考えていくと、やっぱり"attribute"は必要かもしれない。現状すでに「有効・無効」を指定する Available というbooleanの概念はあるが、他にもHookそれ自体の属性がこの件を含めてもう２、３個出てくるかもしれない。

少なくとも、次のメソッドはアリだと思う。
- popResult() : これだけ、破壊的メソッド。array_popを返す。
- firstResult() : 先頭の（最初の）resultを返す。
- lastResult() : 最後のresultを返す。
- allResult() : result配列のコピーを返す。

で、attributeとして
- ignore_null_result : HOOKの戻り値がnullであるとき、result配列にpushするか・しないか。デフォルトはしない。(=true)

って感じだろうなあ・・・。

どうでも良いけど、これ、そのままPageActorやBarrierのチェインに使えない？・・・いや、これらメインのチェイン自体はアイデアとしては不要としてお蔵入りしてるんだけどさ。まあ、多分使わない。また制御周りでややこしくなるから。っつーか、Hookの中でHOOKチェインを操作したりresultを操作したりするのって、よほどでない限り、ないだろう。

Argumentもなんだか無用な気がしてきたな・・・。HOOKにはもう、Hookのインスタンス一つのみ渡すようにしよう。
Argumentという名称自体は、別に悪くないし、かなり的確だと思える。HOOKの引数データ、という意味で端的にあらわしている。・・まあ、argumentに array_unshiftで先頭に &$this を突っ込んでcall_user_func_array すりゃいいだけか。

うん。Argumentはやっぱり有用。

* 定数のprefixについて

どうでもいいけど、今定数系って"XHWLAY_(クラス名のlarge case)_XXXX"になってるけど、"XV_"とか"XH_"とか"XES_"(Xhwlay_ErrorStack"とか"XR_"とかにできないだろうか？タイプがめんどいし、80桁超えやすいんだけど。あとで一括置換しておくか。

→やっぱ、定数名の衝突が怖いのでやめ。

あと、Xhwlay系のインスタンスを保持するときは、$xh とか $xr とかみたいな短縮がかっこいいかもしれない。と思った。HookのSimpleTestで使ってみよう。あとsimpletestのpartial mock、あれ、すげーな。

* pop/pushの実装

あと、pop/pushの実装をarray_shiftとarray_unshift使ってたけど。これ、素直にarray_pushとarray_popでもかわらねえよなあ？
いや、array_shiftとarray_pushという組み合わせは完全にまちがってるよ？けど、これ、先頭を出したり引っ込めたりするか、お尻を出したり引っ込めたりするかの違いだから。
別にどっちだって良いし、であるならば、後で変に邪推される必要の無い、array_push/popで良いんじゃね？

* filterPageName()/filterViewName()のHookについて

filterPageNameやfilterViewNameのHookは・・・ダミー入れておくしか、ないなあ。
Runner自体にstaticなデフォルトHOOK、作ってそれ入れておくか。invokePageActorやinvokeBarrierも同様かな。
・・・あれ？Runner、Abstract必要なくなる？