netail.net

_ Java ▲

java.util.SortedMap で失敗．a.compareTo(b) で比較してから最後に a.equlas(b) するものだと思ってたら，a.equals(b) == (a.compareTo(b)==0) でないといけなかった．比較してから最後にequalsするのは Hash の実装のほうで，そちらと勘違いしていたらしい．一貫性のない SortedMap の動作は保証されないので，結果としてコレクションに投入した compareTo が 0 だけれどequals でないようなオブジェクトがどんどん消されて，あやしげな動作となっていた．

_ Java ▲

try finally 文のfinally節は break や return で外へ飛ぶ際にも実行されるが，実は System.exit で強制終了した場合には動作しないらしい．当たり前のような気はするが，呼び出したメソッド内で勝手に exit されるとリソースがリークしそうなのが気になる．

ふと思ったのだが，Exception.getCause あたりをオーバーライドして，内部で exit するような怪しい例外を throw したら，もしリソースがリークしてたらそのうちシステムがこけそうな気がする．地味な攻撃手段だが :-)

_ 読書 ▲

日経ソフトウェア２月号を読んでたらわりと親切な入門記事があって好印象．

入門向けなどの書籍類の紹介があったが，コトラーのマーケティング・マネジメント基本編（ピアソン・エデュケーション），誰も教えてくれなかったIT英語?海外エンジニアはこう話す（ソフトリサーチセンター）あたりが個人的にはよさげ．そのうち読んでみよう．

_ Calendar ▲

Delphi 7 でコンパイルしたら，hyCalendar 0.6.4 XPテーマ対応版バイナリができた．ほうっておくと対応版ができてしまう様子．（そのほうが楽だが）

_ Delphi ▲

TObjectList など，便利なコンポーネントがいっぱい．……だけど，コンポーネントに埋もれそうだ．

# TObjectList が TList と振る舞いが違うのが# かなり嫌らしいのだが……．# Delete, Remove するかわりに Extract しないといけない．

_ Delphi ▲

Delphi Studio 7 Professional が到着．もう 8 もリリースされようかというところで，今さらといわれそうだけど．

_ メンテナンス ▲

ZAQ メンテナンスのため，SPLAT2004 ワークショップの原稿を早めに投稿．けっこう危なかった……かも．

ネットワークなきゃ，何もできない．

_ 出張３日目 ▲

SIGPRO懇親会〜真野さんたちとの二次会が終わってホテル東海へ無事帰還．

懇親会直前にチェックインしてすぐ出ていたので部屋の設備はあまり把握してなかったが，お風呂とトイレがセパレートで，LANも付いてて，値段のわりにかなりお得な感じがするホテル．

_ [論文] AOPで書き直した場合のメトリクス値の変化 ▲

Tsang, S. L., Clarke, S. and Baniassad, E.: Object Metrics for Aspect Systems: Limiting Empriical Inference Based on Modularity.

Trinity College Dublin technical report.

ある traffic simulator を改造して，非同期処理とかメモリ管理とかをアスペクトとして実装しなおしたとき，AOPでの実装はOOPでの実装に比べてどう変わってるのか，というのをCKメトリクスに基づいて調べた論文．CKメトリクスはそのままでは使えないので，クラスの数としてアスペクトの数も数える，といった簡単な拡張をしている．

アスペクトによって結合が弱まるけれど，登場人物数は増えるので，CBO (Coupling Between Objects) が大きく減少するかわり WMC (Weighted Methods per Class)，RFC (Response For a Class) は増えてしまう．その結果，保守性は大きく向上していたが，WMC と RFC が保守性と理解容易性の足を引っ張る部分がある，と述べている．再利用性は，RFC の影響は受けないと考えられるため向上しており，テスト容易性はほとんど変化がないようだと述べている．

一点，よく分からなかったところは，論文では表を作ってどのメトリクスが保守性・理解容易性・再利用性・テスト容易性のどれに影響を与えるかを示しているが，文章の書き方からして，具体的数値で（たとえば，CBOの減った値に対してRFCの上昇値がどう，とか）向上や悪化を判断しているわけではなさそうなところ．

(追記)An Evaluation of Aspect-Oriented Programming for Java-Based Real-Time Systems Development というタイトルで，ISORC 2004, pp.291-300 に採録されているものがたぶん同じ話だと思われる．

_ [論文] 依存関係を表明として記述 ▲

Jackson, D.: Abstract Analysis with Aspect. Proceedings of ISSTA 1993, pp.19-27, Cambridge, MA, USA.

アスペクトといっても，アスペクト指向のアスペクトではなく，筆者が提案している解析手法のこと．要は手続きごとに，出力変数 x は入力変数 y に依存している，といったデータフロー関係を記述することで，それがない場合にはエラーとみなす．これによって，大事な変数の中身を途中で上書きしてしまうといったエラーを検出することができる．

「少なくともなくてはならない」条件を書くだけなので，仕組みとしては単純だし，誤検出なんかは起きない（そのかわり完全な条件ではないので，素通りの可能性はある）．実現の方法とか，その辺はあんまり書いてなかったので適当だが．

_ [論文] Aspectual Caml の論文を再び読み直してみた ▲

Hidehiko Masuhara, Hideaki Tatsuzawa, Akinori Yonezawa: Aspectual Caml: an Aspect-Oriented Functional Language.

Proceedings of ICFP 2005, pp.320-330, Tallinn, Estonia, Sep 205.

関数呼び出しが join point なのはいいとして，関数自体が変数に束縛されて違う場所で使われたりするから within みたいな静的スコープのポイントカットの使用がちょっと怖い気がした．

関数型言語的に嬉しくなさそうな副作用を伴う処理を全部アスペクト側に追い出すと，プログラムが簡潔になったりするのかなぁ，と思ってみたり．いわゆる計算方法自体と，入出力系などはまったく違うものだから分けて記述しましょう，という考え方はよさそうな気がするけど…．誰かに試してみてほしいような，別にどうでもいいような．