空文字列で悲しいですこんにちは。先日javaではinterfaceを一々定義しないとdelegateが使えないという衝撃的な事実を知りました。理論的には言語レベルで適切な変換をかければ互換性を保ちつつC#のdelegateのような書き方ができるはずなんだけどと脳内で愚痴りつつ対策を考えてみました。interfaceを実装することになります。それで出来上がったのが以下。arg);}言語的に適切にマングリングかければ互換性を保持しつつC++みたいなtemplate汎用性を実現できるのになと脳内で愚痴りながら、2引数版。Foo[0]);}となります。delegate内部で外部変数を使いたいというときに、この方法では独自にクラスを定義しなくてはいけないので面倒です(というか本末転倒)。いうことで以下のようにClosureを定義します。}});といった具合に書けるのです。ちなみに標準でこういうinterfaceが含まれているかもしれないと1.4(Tigerじゃないと駄目?)内を探してみましたが、無いようです。以前どこかで見たような気がするんですが。valueをサポートしてくれないかな、無いとtupleも書けないしつらすぎる。age);}});delegate内部で外部のオブジェクトを複数利用したいときdataとなるクラス(パラメータークラス)を新しくつくるのも本末転倒です。匿名クラスをつくる時点でかなりその処理コンテキストに依存してることは明白なので、外部データ用にテンプレートで対処しておくというのはあまり意味が無い気がします。20:14finalの仕組みをいまいち理解していません。finalという名前から感覚的に避けた次第であります。dependに動作するのか、などです。f.name.equals(data);}})[0];}を定義したい場合にfinalで実装できるのか、という疑問があるのです。mapInheritence)でInstantiatationExceptionになる人はScriptableObject.javaを以下のようにいじくってみるといいかも。{どうやらScriptableオブジェクトを作るのにabstractなクラスのScriptableObjectで実装しているとScriptableObjectのnewInstanceで死んでしまうらしい。上のパッチはScriptableObject以上のクラス階層をprototype展開しないようにする適当コード。ScriptableObjectで実装しなければたぶんこの問題はでてこないだろうけど、http://www.mozilla.org/rhino/apidocs/org/mozilla/javascript/ScriptableObject.htmlここを見る限りではScriptableObjectを使ったほうがよさ気な雰囲気をだしている。http://lxr.mozilla.org/mozilla/source/js/rhino/examples/Counter.javaこれでも使ってるし。このサンプルクラスもmapInheritenceありでdefineClassしたら死ぬんじゃないかと。CVSの最新でもいまだに直ってないような雰囲気。0とかのほうが確実かも。2006/11/17DOMのEventsは遅い?DOMのイベントはノードが深くなればなるほど処理に時間がかかるという不思議なスペックになっています。していくキャプチャフェーズの処理はどうしても避けることができません。ノードからparentNodeをn回くりかえしてドキュメントまで辿りつく処理は避けられないのです。clickとかmousedown程度では気にするほどの処理ではないのですが、たとえばmousemoveを処理しようとすると、マウスを動かすたびにイベントをディスパッチして例のキャプチャフェーズに加えて付加的にですがバブルフェーズまでもが実行されます。これの気持ち悪いところは先にも言ったとおりノードが深くなるにつれて一個のイベントの処理にかかる時間も増加するというところにあります。ちなみにHTMLのmousemoveはcancelableです。そのことを考慮したのだと思います。それで、先日そのことが少し問題になったので対策を考えてみました。避けられないキャプチャフェーズの遷移をなんとかする対策。これの根本的な対策はひとつしかなくて、つまりイベントをディスパッチしないという方法です。EventTarget)。getAttributeの処理が多少重そうですが、これはおよそ一定時間で終了するのでよしとしましょう。この対策は最終手段です。true);として、できるだけイベントハンドリングの処理を省いてしまう方法を使うほうがいくらか健全です。どちらにしても強引なことには変わりありませんが。true);のように無理矢理cancelableにしてからキャンセルしてしまいましょう。この方法は実装に依存します。普通の実装をしていれば動くはずです(DHTMLじゃうごかなさそうだけど)。ちなみにinitEvent系は二回以上呼べます(もちろん実装依存)。これに関連したもうすこし現実的な対策は、documentにaddEventListenerするのではなくて、ノードを保持する構造としてのノードを適当に選びだして、同様なキャンセル処理をaddEventListenerでいれてしまいます。違う方法として(かつ根本的な解決),Eventの中にcaapturableという独自の仕様を作ってしまって、これがtrueの場合にのみキャプチャフェーズを開始するようにするなど。Eventsの仕様に反するような気もします(この際全然気にしないのですが)。Eventsは全体においてしょぼいような気がするのです。KeyEventの仕様ないし。結局のところ有効な対策としては、そもそもイベントをディスパッチしないようにする、キャプチャフェーズの面倒をあれこれ見てやる、getElementByIdとかgetAttributeとかchildNodesとかつまりDOMの全体的な機能を改良する(間接的なのですがリスナ側から使うのは確実なので。Events)、なのかなあと思うのです。つまるところ、普通に考えればDOMNodeInsertedIntoDocumentとかDOMAttrModifiedの処理が頻繁に起こりすぎて普通の実装ではすぐにガタがきてしまうのは必至なのですが、大したことないだろうと楽観視していて痛い目にあったというそういう話です。いう経験をしているのでDHTMLレンダリングエンジンはキャッシュとかアルゴリズムを駆使してできるだけ重くならないように工夫しているのだろうと容易に想像できるわけです。最後にW3Cのリンクを貼っておきます。プログラミングに使う構造の一つとして勉強してみれば、結構ちゃんとした仕様になっていることがわかると思います。Eventsに関してかなり詳しくなったので、これはこれで勝手によしとしています(今ぐらいDOMに詳しければ最初からAjax使ってたと思いますが、実際知らなかったので仕方ありません)。3はどんどん煩雑になっている感じをうけますが)。コンパイルできるといえばできるのですが、Ant特有のフォーマットが原因で正しくエラーメッセージをパースすることができないことがあります。antに-emacsオプションをつければ(標準の)emacsがパースできる形で表示してくれるらしいのですが、.antrcに自動判別コードを書けばもうすこしスマートにすることができるので紹介しときます。-Dbuild.compiler.emacs=true"fi(詳しくはhttp://www.jajakarta.org/ant/ant-1.6.1/docs/ja/faq.html#emacs-mode)ちなみに僕はマクロを使ってcompileの手間を省いています。compileを実行します。C-cをcompileに割りあてているらしいのですが、最近emacsのキーバインディングをいじるのが怖くなて、大体はマクロだとか関数だとかで解決しちゃっています。キーバインディングはできるだけデフォルトで一貫するのが一番かなと思っています。それなりに吟味されているわけですし。場合でも強引に読みにいくらしいことが判明しました。読みにいくのですが、インターネット環境が万全であることを前提としていないアプリケーションでは少しばかり困ったことになります(エンティティに遭遇するまで読みにいくのを遅延するぐらいはしてくれてもいいと思うのです)。引っぱるようにしましょう。ひっぱってくるようになります。返した場合はエラーではなくてデフォルトの振舞いになるので気をつけましょう。シンボルの編集がすこしばかり効率的になりそうです。