vieweditattachhistoryswikistopchangessearchhelp

ラジオアイソトープ的オブジェクト

配線の中を通るモノ(もまたオブジェクトだ)について、
どこから投入したオブジェクトが、どこ(どのノード及び配線)を通って、どこに行き着いたか？を、

知りたい。

というわけで、ラジオアイソトープという言葉を思い出したのでした。

どうすれば実現できるかなあ。


  1. オブジェクトに印をつける。
    まあこれはオブジェクトならば簡単で、同一性という性質を使えばいい。
    つまり、どのIDのオブジェクトを放射線源(?)と見なすか？を決めればいいだけ。

  2. 印がついたオブジェクトを「通した個所」が、通ったことを報告できるような、仕組みを作る。
    どうすりゃいいかなあ。オブジェクトが「通る」ってのはどういう事象を指すんだろう？
    とりあえず
    「変数に代入された」
    「変数じゃないけどそれに順ずるもの(配列とかの要素とか、メソッドチェーンの途中の無名変数(?)とか)に代入された」
    ってのを把握できればいいんじゃないかと思う。
    これは処理系に(ちょびっと)細工すればいいだろう。
    特定の数箇所にwatchポイントなるものを仕掛けられるデバッガは既存なので、
    それを特定じゃなく「全ての」変数(や無名変数?)に一気に仕掛けられるように拡張すればいい。


課題：

--戯

オブジェクトのある値が変化した時に、ある動作を必ず行いたいと思う事が
良くあると思います。単純な例では Excel のような物が考えられます。
Excel ではあるセルの値を変えると参照している他の値も一気に変わる。
Andreas Raab という人が開発している次期 Squeak 環境である Tweak では
こういう事を実現する為にやたら親切なイベントシステムを用意しています。

例えばあるGUI部品に text というフィールドを作成すると、text に値が
格納される時にいちいち #textChanged というイベントが発生します。
これを拾ってtext に関心のあるメソッドが自動的に呼ばれるようになっています。
この関心がある(「配線」にあたる?)情報は、メソッドプロパティ(実態は単なる
イベントと「メソッド送信」の辞書です)に入っています。
関係あるかも知れないので書いてみました --tak

>例えばあるGUI部品に text というフィールドを作成すると、text に値が
>格納される時にいちいち #textChanged というイベントが発生します。

ふーむ。オブザーバの仕組み(や、更にそれを自動生成する上記のような仕組み…ですよね)は、たぶん、
アイソトープ案(^^;とは、「どっちかを使わないと(デバッグとかが)やってられんが、
どっちかを使えば他方はもはや無用」っていう性格のものなんじゃないか、とふと思いました。

オブザーバ(やMVC)を組むと、その個々の内部の(おそらく単純な)構造をちらっと見れば、
もう信号がどこにどう伝わるかは「わかる」んだと思います。作るときも、デバッグするときも。

配線やアイソトープは、どちらかというと、そういう枠組みが無い部分(あるいは最初からそういう枠組みを
導入してないコード(笑))において、それでもなお辿りたい所をなんとか辿る手段は無いものか？と
考えた結果の考えなので。

つまり、散逸されたらタマランから散逸しないような仕組みが欲しいわけです。
それを果たしてくれるなら、オブザーバでもいいし配線でもいい。
不幸にして散逸されちまって頭を抱えたら、最悪、アイソトープで追いかける、と。

＃ええ。ただいま、散逸しちまってるコード(笑)を目の前にして、呆然としてる俺が居るんです(笑) --戯
＃画面上のどのGUI部品が、コード上のどの変数(に代入されたGUIオブジェクト)なのか、とか、
＃そのGUI部品に繋がってるModel(?)はどれなのか、とか、
＃更にそのModelと関連がある他のModelやUIはドレなのか、とかが、
＃熟読しないと訳わからんようなコードでして…

こういう用途では、我々はそのまま文字通り「トレーサー」と呼びます。＞ラジオアイソトープ
ラジオアイソトープがすべてトレーサーとして使われるわけではなく、
トレーサーがラジオアイソトープに限られているわけではないからです。

トレーサー的性格をオブジェクトに持たせるためには、キャスト（代謝）されたときにも
トレース続行可能なような仕組みが必要かも。つまりアイデンティティ判定だけでは駄目。

通過のロギングに際してはアスペクト指向アプローチが大いに役立ちそうな分野ですね。--sumim

ああ。たしかにラジオ(放射性)アイソトープ(同位体)云々は道具名であって、やりたい事柄の名ではないですね。

>つまりアイデンティティ判定だけでは駄目。

toHogehoge系メソッドが返すObjectは、「同じ匂い」を染み付かせる必要が有る、ってことですか。
言語によっては、匂いつけをしにくいクラスが有るかも…

>通過のロギングに際してはアスペクト指向アプローチが

うーん。役立つこと「も」ありそうですね。

変数代入の捕捉については、普通の意味での言語の処理範囲には収まらないような気がする。
処理系に小細工しないと駄目じゃないかな。もちろん最初からそういう仕掛けが有る言語なら話は別ですが。 -戯


このページを編集 (4496 bytes)

Congratulations! 以下の 1 ページから参照されています。

This page has been visited 4147 times.