XPCOM、メモ、Components - FAX
chrome://global/content/nsUserSettings.js @mozilla.org/preferences-service;1(nsIPrefService)のラッパーなんだけど。最近、調べ始めたばかりだから間違ってるかもしれないけど、Mozillaのソースコードには、この手のラッパーが散在してて気持ちがわるい。コンポーネント名を定数で保持していたり、コンポーネントそのものを定数で保持していたり。インスタンスがムダになるのを避けるため、関数でラップしてるものも多い。とにかく、そこここにラッパーと、違うレベルの抽象化の嵐で、コードにポリシーが感じられない。なんじゃらげ。 まず、なんでコンポーネントを受け取ってすぐに全てのインターフェースが使えないのかがわからない。動的言語なのに。いちいちQueryInterfaceで、実質キャストを行わないといけない。この理由がわか
XPCOM、インターフェースのメタ情報を取得する、nsIScriptableInterfaceInfo - FAX
XPCOM、インターフェースのメタ情報を取得する、nsIScriptableInterfaceInfo だらだらいろいろ調べてると、関係ないことが見つかる。 FirefoxのPythonアドオンとか、IRCクライアントの拡張とかあるんだね。 さておき。 やっぱり今日も独自のラッパーシステムを考えてた。 TinyURLを元に戻すとか、そこらへんのXPCOM使ったスニペットを書いてみたりして。 途中でHttpChannelに渡すリスナーをつくるところで、どうにも空実装済みのアブストラクトクラスがないから、コードが短くならない。 本質的じゃないコードも混じっちゃう。 本当に適当なコンポーネント(例えば@mozilla.org/network/stream-loader;1とか)のインスタンスから、無理にメソッドを剥ぎ取って、その情報をもとにスタブを作ろうかとも考えた。 やっぱり、途中のキャスト
XPCOMオブジェクトのインターフェースを一覧する - FAX
XPCOMオブジェクトのインターフェースを一覧する JavaScript mozilla mozilla/extensions/cview/resources/content/cview-utils.js オブジェクト/インスタンスがどのインターフェイスを実装しているかは、Components.interfacesの全てのインターフェースをオブジェクトに当てはめてチェックすることで調べることができる。 オブジェクトが、そのインターフェースを実装しているかは、QueryInterfaceを実行しなくても、instanceofで調べることができた。 速度も、こちらの方が早かった。 function getInterfaces(obj){ var result = []; for (var i in Components.interfaces) { var ifc = Components.in
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
