Re: [MD:4307] COM support plan

[Shun-ichi GOTO <gotoh@xxxxxxxxxxx>]

# ナガノくんをハゲさす会、(兼 披露宴(?))は出席できず残念
# すっかりウラシマなのですが、
# なんとも楽しそうな話題なので(束の間だけど)ちょっと生きカエル

>>>>> at Mon, 31 Mar 2003 13:54:53 +0900,

> 2.Architecture
> 
> C level で COM Object は Lisp Object と等価になるよう実装することが求め
> られる。elisp から COM Object を見ると Lisp Object とまったく同じように
> 扱えるようにする必要がある。それには以下をサポートしなくてはならない。
> 
>   (1) ライフサイクル管理 (もちろん GC とかも)
>   (2) COM の型と Lisp の型の完全な相互変換
>   (3) ...

随分以前にこの類の話が出たさいに、himi さんもいっていたと思うのだけど、
FSF Emacs には object の destructor がない以上、COM object を正しく解放
処理するためには first class object にする必要性があるという話があると思
います。それがどれほどの作業量なのかは不明ですが、結構な決意がいるのか
なぁ。

# ちなみにEmacs 20.5 の頃にあったCOMサポートの試みでもそれは課題に上がっ
# ており、不完全なのを自覚した上で、解放処理ははしょっていました。


> # ここ同期とか排他とか 3 つ以上ポイントがあったと思うのだけど、酩酊し
> # てダメ...

これはどんな話なのかなぁ。(興味あり)

COM呼出は外部処理なので、elisp スレッドで直接呼ぶ構造にはせずに別スレッ
ドで処理する、とかそういうネタ？


> elisp level では COM Object の property や method をいわゆる Object と
> して簡易に扱えるように luna の wrapper を用意してもよい。wrapper によっ
> てユーザーは、COM Object を luna object であるかのように利用することが
> 可能になる。

それは是非実現したいですね。

ただluna にしてもeieio にしても、それよりもまずやるべきはCOM Type
Library への問い合わせとInvoke による呼出し機能をかためることで、
次いで、method 問い合わせによる関数へのマッピング、などと思いつつ。

ついでにいうと、DLLの関数への関数bind も出来ると嬉しいので考慮したいな。
具体的には list にてspec を与えてbind するとか妄想。

も一ついうと、COMに手を出すなら .NET もやりたい。
出来そうなきがしてる(熟慮なし)

## 最近.NET 漬け...

--- Regards,
 Shun-ichi Goto  <gotoh@xxxxxxxxxxx>
   R&D Group, TAIYO Corp., Tokyo, JAPAN