log
頂点と辺のリストが分かれている必要があるか、という物理演算の対象での疑問点について。 一つのリストにまとめる必要はないが、別々のVectorとして実装されているのには問題がある。 例えば今、modVertex, modEdge, modLawという3種類のよく似たインターフェイスがあるが、これはVertex, Edge, Lawがそれぞれ別個のVectorとして宣言されているからに他ならない。これらが一つの「名前をキーとしリストを値とするマッピングオブジェクト」に入っていればmodify("Vertex", vertexID, params)というように一つの窓口に集約できる。
「一つの窓口に集約できる」のはいいが、集約する必要はあるのか？これはYesだ。ここで修正しておかなかった場合、物理演算の引数として渡される名前付きリストの作成の実装をするのにも3つのコードクローンが発生する。将来的に他の場所で問題を発生させないとも限らない。設計の不備は早めに直しておくべきだ。
現状で、Vertexだけ名前と頂点のマッピングであり、EdgeとLawはただのリストだが、これは全部マッピングにすべきか。少なくともそうすれば「デフォルトの物理演算で3番目に設定されているバネの力の係数をいじるためにget(2)する」なんてバッドノウハウはなくなる。名前で取得できるから。
LawをVertexやEdgeと同格にしたら、Aggregatorクラスが持つフィールドがなくなったのでaggregateメソッドをGraphクラスに移動してAggregatorクラスは削除。
gettextって、同綴異義語があったらどうするんだろうね。
剛体制約は問題なく動いていますな。回転速度の係数くらいいじる必要があってもおかしくないのに一発で動いてむしろびっくり。でもこれは画像を貼っても面白くないので撮るなら動画ですねぇ…。やっぱり動画か…。
HashMapは同期化されない、と書いてあるからHashtableは同期化されるんだと思っていたのですが、ConcurrentModificationExceptionが送出されるケースはあるようですね。synchronizedしないといけないんですかねぇ。そういう手間がないんだろうと思ってHashtableを使ったんですが…。
剛体制約と壁張り付き制約を両方入れると粘っこい壁にスポンジをこすっているような気分。やっぱ動画か…。
画面外に頂点が出ないようにする制約も作りました。
JSONとXML-RPCの出入り口を共通にするのはどちらもJavaオブジェクトを直接触ることができないからいいのだけど、Jythonまで共通にしてしまうとせっかくのJavaオブジェクトを生で触れるメリットが失われてしまいますね。三層構造。
物理演算の対象になる頂点を保存する場合にどうするか。名前のリストで保存するのはてっとりばやいが、とりあえず辺や頂点などで重複する名前がないように保証する必要がある。あと、そういう形で保存した物をロードして新しい頂点を追加したら、新しい頂点に物理演算が働かないのが自然ですな。それは使い勝手が悪い。SpringEdge("allEdge")というように名前付きリストの名前で参照する方法なら、後からリストの内容が変化しても問題はなさそう。数の少ないハッシュから引いてくるだけだから大したオーバーヘッドにもならない。この場合、物理演算が対象の名前を覚えておくか、対象から名前が引けるか、どちらかが必要になると思う。名前付きリストを文字通り「名前とリストがくっついたオブジェクト」にしてしまえば後者の条件が満たされるが…。
各頂点を名前付きで作成した後でanchoredListにその名前を入れていくよりは、各頂点にanchoredという属性をつける方が自然。Vertexなどに「存在しないプロパティ」をセットした場合にはHashtable Vertex#propertiesに値が入るとか。それならanchoredも頂点作成時にparams = {"anchoredPos": (0, 0)}と自然に書ける。うむ。これがよさそう。
