DOM Element Proxy

Irenka

めも。

VM越しにプログラム構造を使うときにはどう考えてもProxyが必要。ってのは当然として、実はもっと身近な場面でProxyが必要な感じ。

  • /project1
  • /project2

IrenkaのDOMはルートパッケージを基とするツリー上の構造で、親子は双方向リンクで接続されている。一方で、project[12]は共に異なるルートパッケージを有する(クラスパスの衝突を防ぐため)ので、project2のルートフォルダからproject1の要素を参照する場合、その要素はディープコピーとしてproject2のツリー上に配置する必要がある。

これはproject1の要素のProxyを作ってproject2に配置しないとひどいことになりそうな予感。参照プロジェクトに触る際には名前参照可能な要素＋αくらいしか触れないはずなので、比較的少ない作りこみで何とかなるかもしれぬ。思考実験は死ぬほど必要な感じですが。

Irenkaが動くようになり始めてきたのでたぶんIrenkaを使ってProxy作れるけど、なんかまだ怪しい部分がある感じ。この問題は来週頭くらいまでにインスピレーションが来ればいいなぁ。


個人的なメモ：

  • CtXxxSlaveはProxy使わない
    • ただし、CtXxxSlave#setMasterにはProxyのまま渡す。
    • 意味的にそちらの方が正しい
  • Synthesizer -> ProxySynthesizer？
    • 5人日じゃ済まない
  • getParentはスイッチャ渡しとく？
    • 微妙
  • Proxyの先がdeactivateしたとき
    • activate失敗時は？
  • CtMethod@Proxy#getBody()
    • これは仕様として明記
  • CtField@Proxy#getInitializer()
    • たぶんCtMethodより根が深い。定数解決とかはそれなりに