netail.net

_ ダイクストラ ▲

ダイクストラが 8月6日，死去．謹んで冥福を祈りたい．

情報科学を専攻してる人間にとっては偉大な先駆者のひとりだけど，asahi.com の "おくやみ" 記事とかには載ってない．シャノンは載ってたような気がするんだが…．

_ Intentional Programming ▲

Intentional Programming - Innovation in the Legacy AgeCharles Simonyi

Intentional Programming は，プログラマの意図 (Intention) を再利用することが目標?Intention に，そのソースコードへのマップのやり方だけでなく，エディタでの表示をどうするかとか，色々な情報を付加している．

うまく使えば，抽象的なボキャブラリを言語に導入できる．たとえば forall x in A, do {} を Iterator 表現に置換するとか…．でも，Intention 自体を抽象的に書けるかどうかとか，色々問題もありそう．個人的には，IDEの支援がないとまったく利用不能なツールは，しかもツールの実装そのものが高コストなものは，好みではない．

どうでもいいけど，IP (Internet Protocol) という既存の言葉とかぶる略称はやめてほしいなぁ．

_ 論文 ▲

Support for Subtyping and Code Re-use in TimorJ. Lesile Keedy, Gisela Menger, Christian Heinleinをチェック．Subtyping (is-a) と，実装の再利用としての継承というのは別物だから，区別して使えないといけない，という主張．この筆者が作った(?) Timor という言語では，impl ArrayDEQueue of DoubleEndedQueue reuses ArrayQueueといったようにインタフェースは DoubleendedQueueだけど実装だけは継承しているみたいなことが書けるらしい．(ここで Queue と DoubleEndedQueue は特に関係のない type， type とは Java でいう interface みたいなもの)これは，Java の "implements" などにくらべて記述の自由度が高いので，面白いかもしれない．

_ JREVEAL, Java Decompiler ▲

TOOLS (Technology of Object-Oriented Languages and Systems)2002 の論文でREVEAL というのが紹介されてたので検索してみるとhttp://www.jreveal.org/index.htmlという Java の逆コンパイラを発見した．逆コンパイラが役立つかどうかはともかくとして(設計書の残ってないバイナリコードのメンテナンスには役立つか?)興味深いシステムである．

_ 論文 ▲

http://www.fuka.info.waseda.ac.jp/~washi/diary/200202.html

>[TOOLS Pacific 2002] 初日>http://www.cse.unsw.edu.au/tools/>>"Specifying and Implementing the Operational Use of Constraints in Object-Oriented Applications">Verheecke, B. and Straeten, R.V.D. (2002). >>Constraints を元のクラスとは別の Constraints Class を>自動生成して、その内容を CASE Tool から生成した元の>クラスに　”埋め込んで”検証する試み。

気になるアプローチだったのでチェックしてみた．

OCL と呼ばれる制約記述言語を UML に加えて，クラス図からコードを生成するときに検証用のコードと，それを破った場合の例外 throw 文が加えられる．ツールによるサポートが前提だけど，面白い試みだと思う．ただ，throw されうる例外は必ず正しく catch しないと意味がないので，コードを書く人が不慮の例外発生，および不慮の例外 catch に気をつけないといけない．たとえば，リソースの解放は確実に finally をかましとかないとまずい，とかいうことになるわけで，その辺は不安がある．

_ 論文 ▲

Constantions A. Constantinides, Atef Bader and Tzilla Elrad.An Aspect-Oriented Design Framework for Concurrent Systems.ECOOP '99 Workshop on Aspect-Oriented Programmingを読み直し．アスペクトの階層化という言葉で引っかかってたけど，(C + A) で合成した結果に対してさらに別のクラス C' とアスペクト A' をくっつける，といったような階層化らしい．これは，システム全体を横断するようなアスペクトが他のアスペクトから影響を受けたくない場合などに有用．AspectJ では現状ただの足し算になるので，「このアスペクトには他のアスペクトはくっつくな」と宣言できないんだけど，それが実現可能になる．(この「他のアスペクトはくっつくな」表明は， 逆にくっつかないと困る場合もあるので一概にはいえない問題． たとえば，ファイルへの出力をすべてネットワークへマップするとか いうアスペクトがあった場合，それはログ吐きアスペクトにも くっつかないとダメ）

_ 論文 ▲

読んだことのある論文の管理がいい加減だと，どうしても複数回同じ論文を読んでしまいがち．何か組織的な方策はないものかしら．単に論文タイトルでリストを grep するだけって芸がないしなぁ…．