2004-09-05

Konfabulator on Windows!?

http://www.widgetgallery.com/WindowsShot.jpg

すげー。すげーよ。

メモリホル

どこからそのカタカナを拾ってきたのかおしえてくらさい ＞Kevin Moore でもKevinのdownload editionsのページは、個人的にとっても好印象です。ghost booksもdownload editionsに置いてくれていたらなあ、と思いつつ、CDの方を買うことにしますた。実は最初のchroma key以外はそんなに趣味じゃないんだけどね…

DOMのデバッグはあっさり終わるが、XSLTやXPathみたいに、いちインスタンスのノード情報がコロコロ変わるXPathNavigatorを真面目にデバッグしていると非常に面倒だ。オブジェクトの内部状態を常にヲチしていないとデバッグが難しい（だからVS.NETベースでやりたくなる）し、VSを使っていてもconditional watchは実行するのにものすごく時間がかかるから、XPathNavigatorはおよそ実戦には向いていない、というのが、実装していた僕の感想だ。

だいたいXPathNavigatorのが速いっていう話は不自然だ。あれだけツリー編集可能なAPIにしておいて、DOMよりそんなに速くなるわけがない。IRevertibleChangeTrackingを安全に実装するには、ノードの生成もWriteString()などで最適化せずに、XPathNavigator実装でXmlDocumentNavigator（ええと、MSではDocumentXPathNavigator）のように連結チェックをした方が良い（通常連結は発生しないので、ここでかかるコストはほとんど無い）。んで、たぶんこの辺は収拾がつかなくなったので、MSとしてはXPathDocumentに大してニーズもないめんどうな機能を追加するのはやめようよ、ということになったのだろうと思われる。実際、.NET 2.0 beta1のXPathDocumentは大して速くない。

7月の終わり頃にこの辺でおもちゃを大量生成していた時に本家monologueにも書いたけど、XPathEditableNavigatorを実装するのは、XPathDocumentの.NET 2.0 beta1バージョンを実装するよりは全然簡単だ。どれくらい簡単かというと、僕がXmlDocumentベースで作って1日かからなかったくらい。まあ、バグは多少あったけれども。だから、XPathDocumentが消えてXPathEditableNavigatorが残るというのは、まあ僕としてはよく分かる話ではある。editable XPathDocumentがどこに行くのかは、分からないけれども。

DOMより10倍以上速いっていう説もあったけど、それは滅多に使われないprevious-siblingやprevious軸を見に行ったときの話だけだし、XmlDocumentだってPreviousNodeをフィールドとして持たせればすぐに速くなる。じゃなかったらXPathDocumentだって高速に実装できるわけがない¹。XmlDocumentはあえてそうしていないだけ。XmlDocumentを改善する、と言われている現時点で、これでDOMのが遅いっていうのは、低レベルな煽りにすぎない。

あとSelectNodesはXmlNamespaceManagerを生成しなければならないから不便、みたいな言説も見られたけど、そのノードでXmlNodeReaderを生成して渡すだけで良いはず（XmlNodeReader1つの生成コストなんて、Clone()だらけのXPathNodeIteratorに比べたら無視できる量だ）。

W3C DOM

というわけで（↑とは全然関係なし）、SVGドキュメントで記述されるであろうスクリプティングを、正しく互換性を高めるように作るには、DOMインターフェースはやっぱ小文字で名前を始めないとダメなんだろうなと、DOMのほとんどのインターフェースのひな形をC#で書き上げてから思ってしまった今日この頃。