-
Notifications
You must be signed in to change notification settings - Fork 0
Interface Definition Language
RPCやCORBA，COMにおいて，モジュールのインタフェースを定義するために 使われる言語．インタフェースと実装の分離がポイント．
いまいちIDLって好きになれないんです．必要性はわかるけど，ユーザが いちいち書いたりせずランタイムで自動化できないかって思うんです． オブジェクトモジュールフォーマットにリンクのための情報を入れると． で，必要ならリンク時に型やスタック利用の違いを吸収するためのスタブを はさむ(これはIDLより実行時のオーバヘッドは大きくなりそう)．
-
たしかdRubyはランタイムでやるんでしたよね。
-
IDLつまり静的リンク(ですよね?)も、そのメリットを十全に活かすべき実装を していなければ、宝のなんとやらになるんでしょうね。 以前仕事で関わってた某システムが、ちょっとアレだった(笑)。 もう少し能力と体力と暇があったなら、Ruby(つまり動的リンク)で ラッパーを書いてしまってたかも。
- IDL=静的リンクってことはないと思いますが．むしろ動的リンクが普通なのでは? 言葉の定義の問題かな?
-
逆にいえば、動的リンクにしたとしても、そのRTTI調査結果を、 たとえばキャッシュとか…できますかね…もし出来れば、 ペナルティはかなり減るのかなーとか。 -戯
- dRubyのことは知らないのですが，動的リンクは基本的に最初の 実行時にしか起きないので，ペナルティはその一度だけです．リンク確定後は 静的リンクと性能的な違いはありません．
IDL うんぬんという話は食わず嫌いなだけな気もしますが．
- 単一言語，単一 OS でやっている分にはニーズがないもんな．
- 異機種混在とか，言語中立とか考えると，ピボットとか中間コードというか
共通表現が必要になって来る．
- IDL はそれを実現するためのポピュラなアプローチ．
- Planet は機械語レベルやるアプローチ．
.NETの MicrosoftIntermediateLanguage も要チェックかも．
IDL とオブジェクト指向データベースのスキーマ進化みたいな動的な変化を組み合わせないだろうか?
- データベースの世界では当り前?
研究プロジェクト
-
[http://www.cs.utah.edu/flux/flick/ Flick] (Univ. of Utah)
- 従来の IDL コンパイラは単一の IDL を想定している．Flick では， 複数の IDL に対応したフレキシブルな IDL コンパイラを目指す．
- 従来の IDL コンパイラではネットワーク通信を性能のボトルネックと 想定しているが，ネットワークメディアは高速化しており， スタブの最適化が不十分である．
- Flick はフロントエンド，プレゼンテーションジェネレータ，バックエンドの 3フェーズから成る．
-
[http://www.cs.utah.edu/flux/knit/ Knit] (Univ. of Utah)
-
[http://l4ka.org/projects/idl4/ IDL4]
- IPC，コンポーネント間通信の性能を上げるため，汎用性よりも L4 の IPC 機構，x86 に特化したアプローチを取っている．
-
[http://os.inf.tu-dresden.de/dice/ DICE]
- これも L4 ([http://os.inf.tu-dresden.de/drops/ DROPS]) 関連のプロジェクトだけど，IDL4 より汎用的なものを目指しているみたい．
- また，L4 ベースの [http://www.l4ka.de/projects/SCOS/ SC/OS] は Flick を利用したコンポーネントOS らしい．
-
[http://www.parc.xerox.com/istl/projects/ILU/ ILU] (XeroxPARC)
- ''The Inter-Language Unification system (ILU) is a multi-language object interface system.''