From: Itou-T15@...
Date: 1999-12-20T17:57:02+09:00
Subject: [ruby-list:19740] Re: ClipBoard I/O  対応

＞でも、JavaのRunnableを考えると、interfaceは「お作法」だと思います。。。

伊藤です

雑誌購入に関連する話としてはオンデマンド配信がある、
読者の好みプロファイルや文献検索式を事前登録しておく。
これの類比で考えたら、オブジェクトの使用ソースの側で
「この様な」インターフェイスに互換なものなら可、という
宣言をして解決できないか？
既存のものは「提供インターフェイス宣言」と言える、
これと「要求インターフェイス宣言」を当てて夢の
アダプターレス言語（仮面クラス内部発生）
でもどうやって？
コンパイラ／リンカ／プロファイラーで要求インターフェイス
の自動発生。しかし動的言語なら単なるヒントにすぎないかも。

人はテストランの比較やソースを読んでメソッドの互換性を
知っているからアダプタを書ける。しかし言語処理系は
プログラムの意味を判らない。（２バイト文字が処理できるか
事前判定するソフトはない、あると助かるが）
できるのは「同族の子孫は似ている」が判る程度。
「他人のそら似」はキャッチできない。

ドキュメントベースの支援システムで人がアダプタを書くのが
結論かな？

オブジェクトの互換使用を自動処理するのは
「はるか銀河系のかなた・・・」になりそうだ。

話代わって
UNIX なら /dev/Clipboard を作ってコマンド行に書けるか？
Win ではどうしようも無い。
責任をコマンドインタープリタに持って行けるか？
シェルはOSのオブジェクトをどの程度まで直接操作しているか？
プログラム起動は文字列を作ってOSに投げているだけに見える。
ファイル名は文字列のままでファイルハンドルでないようだ
文字列からファイルハンドルまで落とすのはアプリの仕事。

もしシェルの完全オブジェクト化（対話型Ruby）で
オブジェクトをArgvで渡せるなら、シェル内でClipboardから
InputTextStreamを作りRuby起動時に渡せる。

アプリ側でも対応が必要。しかしコンポーネントとしても動く
ソフトは文字列のArgvからGetOptsをしてから本当のオブジェクトを
作って動き出すのと、直接objを受けて直ぐ動くのをできると
いいかもしれない。OSが邪魔しなければ。

〓