アカウント名:
パスワード:
コンポーネントねえ。それならば、たとえばrubyのdelphiバインディング (逆でもあるが)であるApollo [yun.co.jp]なんかは、どう呼べばいいんでしょうか?
コンポーネントってつまりはクラスライブラリであるわけだから、 rubyでだってhogehogeバインディングを作れば同じことであるような。
Unixで育った人達はPerlとかばっかり見てるからスクリプト言語はCベースで半手作業で言語バインディング用意するものだと思ってる人が多いかもしれないけど、そんなことはないです。IDLを使わないやりかたで数少ない自動的なC言語バインディングを持ってるのがGuileです。あとライブラリだけどGCCに入っているlibffiっていうのも同等の機能を有します。ちなみにXPCOMの下のxptcallはC言語ではなくC++のメンバ関数をディスパッチできる強力なライブラリなのです。
そういうメタな部分の機能(もちろんきちんとしたもの)を1つ策定すればいいんだから。
>C++のメンバ関数をディスパッチできる強力なライブラリ もしやそれって、あの糞C++の(dispatch回りの)柔軟性の無さを 迂回できるようになるライブラリですか?だったら嬉しいというか有意義だなあ。
>スクリプト言語側にEval相当があれば実装できて当然 ってのはもしかして、...(略)...任意の(メタライブラリに準拠した)ライブラリをノーコーディングで呼べるようにする、という手順のことを、一言で「eval」と言っている、のですか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
敷居は低くなった? (スコア:1)
んじゃったら、RubyとかPythonとかあるってか。
ま、面白いアプローチなので期待。
.::.:... .::....: .::...:: .::.:.:: .::..:.: .:::..:.
I 1 2 B H4[keR. :-)
Re:敷居は低くなった? (スコア:0)
Re:敷居は低くなった? (スコア:1)
そういう捉えかたをすべきものなのかどうか?と、ちょっと惑います。
コンポーネントねえ。それならば、たとえばrubyのdelphiバインディング
(逆でもあるが)であるApollo [yun.co.jp]なんかは、どう呼べばいいんでしょうか?
コンポーネントってつまりはクラスライブラリであるわけだから、
rubyでだってhogehogeバインディングを作れば同じことであるような。
で、JavaScriptといえば普通(?)のPrototype型OOP言語であり
手続き(?)もFirstClassObjectなのでしたよね。
とくれば、まあ普通の(良質な)スクリプト言語と同じくらいの
記述能力は有るだろうから、それでweb以外のアプリだって
書きたいと思うのは人情として不思議じゃないだろうな。
該当言語だけで素直に書くのが困難な部分は拡張ライブラリとしてくっつける。
くっつけた結果が今回のコレだということ、かなと。
ま、スクリプト言語で汎用(?)プログラムを作るための基盤が
また少し広がった、という感じでしょうか。
ところで、callbackの記述のしかただけど、ruby方式よりも、
「括弧をつけたらその手続きの呼びだし。つけなければ
その手続きをObjectとして扱う」というC類似方式
(であるJavaScript)のほうがしっくりくると感じるのは俺だけだろうか?
Re:敷居は低くなった? (スコア:2, 参考になる)
Unixで育った人達はPerlとかばっかり見てるからスクリプト言語はCベースで半手作業で言語バインディング用意するものだと思ってる人が多いかもしれないけど、そんなことはないです。IDLを使わないやりかたで数少ない自動的なC言語バインディングを持ってるのがGuileです。あとライブラリだけどGCCに入っているlibffiっていうのも同等の機能を有します。ちなみにXPCOMの下のxptcallはC言語ではなくC++のメンバ関数をディスパッチできる強力なライブラリなのです。
Re:敷居は低くなった? (スコア:1)
あれれ?あーゆーものはevalだけで全部つくれると限らないような気がしましたが、
気のせいでしょうか?
evalだけではinterfaceの向こうの別世界(もしそれが別世界ならば)と
対話する術が無いですから。
>ここで言ってるコンポーネントってインタフェースによって言語非依存に再利用できるオブジェクトの事を言ってるんだから。
ふむ。じゃあ、その「クラス」ライブラリについて、特定言語だけを
その出自&供給先にしなければ、それで良いわけですよね。
じゃあ(ある意味で)簡単だな。
そういうメタな部分の機能(もちろんきちんとしたもの)を1つ策定すればいいんだから。
そういやjavaのbytecodeを生成する言語は「たくさん」あるそうですが、
それのもう少し先の部分が、その「コンポーネント」なんでしょうね。
ところで、言語非依存というけど、object(class)のアーキテクチャ自体は
いろんな言語がいろんなものを提示しているわけで、
共通に使えるinterface仕様を策定しようとしたら
どうしても最大公約数なものになっちゃいますよね。
それって時として辛くないですか?
バイナリレベルでの接続性は確保できても、概念レベルは結局解決しないのわけだから。
#あるいは逆に、うんと柔軟で多機能でナンデモアリに作っておいて、
#実行時に状況次第で色々な制約を課す、か。
蛇足:
>Unixで育った人達はPerlとかばっかり見てるから
俺はunixで育ったわけじゃないし、perlは知りませんし。
あえていえばdelphiで育ったってか(ぷ
ちなみにCOMとかも呼べますねdelphi。
ただdelphiネイティブの「コンポーネント」と比べて、COM呼びだし回りは、概念の繁雑さにうんざりしますが。
>GCCに入っているlibffi
それを知ってる人は「unixで育ってない」人なのでしょうか?(^^;
>C++のメンバ関数をディスパッチできる強力なライブラリ
もしやそれって、あの糞C++の(dispatch回りの)柔軟性の無さを
迂回できるようになるライブラリですか?だったら嬉しいというか有意義だなあ。
やっぱり手続きはFirstClassObjectということにして、
それを適当(^^;なobjectにぶらさげるとメソッドと見なされる、
という(JavaScriptでも採用してる)Objectアーキテクチャが、
すっきりしてて良いなあ。C++みたいなのはウザい。
うーん。ひととおり書いてやっと思い至ったけど、
>スクリプト言語側にEval相当があれば実装できて当然
ってのはもしかして、まず「任意のライブラリと結合できるようにするための
メタライブラリ」へのバインディングを該当言語に作りこんでおいて、
つぎにそのメタライブラリと(該当言語の)リフレクション機能を駆使することで
任意の(メタライブラリに準拠した)ライブラリをノーコーディングで呼べるようにする、
という手順のことを、一言で「eval」と言っている、のですか?
#それなら俺もいつもやってる(^^;
Re:敷居は低くなった? (スコア:1, 興味深い)
--
...よい子は早く寝ましょう。