Whiteのふりーとーく

仕事：ポポポインタに悩んでいる。

とりあえずのところ清く正しく(?)Table -> TableData -> TableRow -> TableCell という参照構造のオブジェクト群を作ってみた。TableとTableDataを一体化してないのは移植元におけるTableの継承クラスに標準のTableとは異なるデータ構造を持つ奴がいたから。いちおう分割しておけばポリモーフィズムが使えるかなという淡い期待。そしてVectorなど使わずTableのインスタンス生成時に(最大)row数とcolumn数を指定して配下インスタンスを全部こしらえるというダサいがメモリ管理に優しい方針で。

Tableに出すものはおおむね通信の結果得られるものだが、通信して結果を得るのたびにメモリ割り当てをしたりするとメモリのフラグメンテーションが大変ひどいことになる。そしてBREWの駆動モデルではそういう状態になるとシステム全体を巻き込んでくれやがる。そのへんiアプリではJavaであることで大きな恩恵を受けていたのだなあ。明らかにVMがメモリリークしてる機種もあったけれど。

_ということで素組みしてコンパイルは通るようにしたが本当にこれでいいのかはまだわからない。メモリ管理機構への優しさを考えるならば、TableRowなぞ削ってTableDataで直接TableCellの管理をした方がいいような気もする。素直に組んだ場合のデストラクタ呼び出しチェーンとか考えると特に。終了処理だって1秒を要求されるのであろうから。あるいはTableCellManagerなんてのを作ってそこから割り当てを受けるみたいな機構とかか。

本当に至る所で「1秒」が鎌首をもたげてくる。SandBoxなしにダイレクトに駆動させるモデルの弊害……というか弊害の方が多すぎるような気がしてならない。なんでOSでプロセスかなんかで分けねえんだよ。たぶんプロセスをボコボコ起こすって概念がOSの側にないんだろうなあ。規格を作った時期を考えれば現実的な回答だったのだろうが、今となってはその現実性が足を引っ張っているのだろう。将来性だけはバッチリだったJavaとはそりゃあ差がついて行くであろうて。