アカウント名:
パスワード:
XPCOMはAPIの古さから、そろそろ捨ててほしいです。逆にXULは、Windowsのピクセル依存UIやHTML/CSSの制限を無視して作られたため、当時のUI言語としてはピカイチでした。HTMLのサブセットという扱いでも良いので、XULを生かす方法は無いのでしょうか…
http://www.ibm.com/developerworks/jp/webservices/library/co-xpcom.html [ibm.com]>XPCOMは、確かにスレッドをサポートしています。ただし、スレッド・セーフなコンポーネントは標準的なものではなく、むしろ例外的です。>ほとんどのコンポーネントは、メイン・アプリケーションと同じスレッド内に共存するように記述されるからです。
古いって捨てる理由になるの？
古いってのは時間が経ったという意味ではなく、捨てるべき時が来たってことじゃないのかな。
既にjs-ctypesというものがあるので、XPCOMは要らない気がします。安定したAPIなんて幻想。
原理主義者にはアンチパターンってだけで十分かと。
Fx40でXPCOMはサポート切れますよーhttps://www.mozilla.org/en-US/firefox/40.0beta/releasenotes/ [mozilla.org]
> Removed support for binary XPCOM components in extensions, use addon SDK "system/child_process" pipe mechanism for native binaries instead
正確にはこうですよね？間を省き過ぎ。
Fx40で（、拡張機能内で使用される、バイナリの）XPCOMはサポート切れますよー
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
捨てるべきはXPCOMであって、XULではないのに… (スコア:3, 興味深い)
XPCOMはAPIの古さから、そろそろ捨ててほしいです。逆にXULは、Windowsのピクセル依存UIやHTML/CSSの制限を無視して作られたため、当時のUI言語としてはピカイチでした。
HTMLのサブセットという扱いでも良いので、XULを生かす方法は無いのでしょうか…
http://www.ibm.com/developerworks/jp/webservices/library/co-xpcom.html [ibm.com]
>XPCOMは、確かにスレッドをサポートしています。ただし、スレッド・セーフなコンポーネントは標準的なものではなく、むしろ例外的です。
>ほとんどのコンポーネントは、メイン・アプリケーションと同じスレッド内に共存するように記述されるからです。
Re: (スコア:0)
古いって捨てる理由になるの？
Re:捨てるべきはXPCOMであって、XULではないのに… (スコア:1)
古いってのは時間が経ったという意味ではなく、捨てるべき時が来たってことじゃないのかな。
Re: (スコア:0)
既にjs-ctypesというものがあるので、XPCOMは要らない気がします。
安定したAPIなんて幻想。
Re: (スコア:0)
原理主義者にはアンチパターンってだけで十分かと。
Re: (スコア:0)
捨てる理由としては十分だと思うけど。
Re: (スコア:0)
Fx40でXPCOMはサポート切れますよー
https://www.mozilla.org/en-US/firefox/40.0beta/releasenotes/ [mozilla.org]
Re:捨てるべきはXPCOMであって、XULではないのに… (スコア:2, 参考になる)
> Removed support for binary XPCOM components in extensions, use addon SDK "system/child_process" pipe mechanism for native binaries instead
正確にはこうですよね？間を省き過ぎ。
Fx40で（、拡張機能内で使用される、バイナリの）XPCOMはサポート切れますよー