log
まず、Zオーダーを導入して、描画の順番を切り替えられるレンダラを作成するという方法。子頂点への辺より先に親頂点を描画することでとぎれを解決する方法です。これは、それぞれの頂点に適切なZオーダーを割り振る必要性が(プラグイン作者側に)出てきはしますが、コンピュータにはあまり負荷のかからない方法です。
もう一方は、頂点に辺の端点を返すメソッドをつけるというものです。 これはNarVisualizerのような頂点を作る際にも役に立つかも知れません。しかし、毎ステップ端点の計算を行うので計算量が多いかも知れません。
__ オブジェクトは実際にはPOJOだけどXML-RPC経由でいじるためにはクラス名とパラメータの対。これでオブジェクトの生成や保存に関しては問題ないけども、インタラクティブに動かすには「生きているオブジェクト」への参照が必要。もちろんこれもXML-RPC経由でいじれなければ行けないので、String nameを使う。全てのオブジェクトがnameをキーとしてハッシュに入っていれば、nameをポインタのように使うことが出来る。
GraphクラスがだんだんGraphクラスっぽくなくなってきた。 そもそもアプリケーションにひとつだけのインスタンスで、グラフのくせに物理演算まで持っていて、今後さらに全てのXML-RPCアクセシブルなオブジェクトを持つようになると…どう考えてもGraphじゃない。しかもrenderメソッドをRendererに移したのでRenderableGraphはとことん間違ったネーミング。
リファクタリング。いい名前が思いつかないのでまだGraphのままだけど。
__ makeTable, getNamedDict, namespaceなど、同じ物に違う名前が付いている。実体はHashtableで、キーが文字列なのでDictionaryであり、かつキーが文字列のDictionaryをnamespaceに使っている。さぁ、どれが一番適切な名前だろう。 とりあえず、Tableはダメかな。Hashtableは使っているけど、それは別に重要ではなく、HashMapでもよくて、むしろMapと呼ぶ方が適切。 やっぱnamedDictなのかなぁ。「Dict」で「キーが文字列のマッピング」であることをほのめかして、かつそれが名前で管理されている、と。ただ名前とDictは1対1対応じゃないんで、namedなのかといわれるとちょっと違う。Dictでいいのかな…。
