アカウント名:
パスワード:
コンポーネントねえ。それならば、たとえばrubyのdelphiバインディング (逆でもあるが)であるApollo [yun.co.jp]なんかは、どう呼べばいいんでしょうか?
スクリプト言語へのインタフェースは、スクリプト言語側にEval相当があれば実装できて当然ですよね。でもそれは一対多の関係でしかないし、言語依存です。DOMはそのずるい(?)やり方を標準化してしまったわけだけど、これは置いといて。
コンポーネントってつまりはクラスライブラリであるわけだから、 rubyでだってhogehogeバインディングを作れば同じことであるような。
「コンポー
そういうメタな部分の機能(もちろんきちんとしたもの)を1つ策定すればいいんだから。
>C++のメンバ関数をディスパッチできる強力なライブラリ もしやそれって、あの糞C++の(dispatch回りの)柔軟性の無さを 迂回できるようになるライブラリですか?だったら嬉しいというか有意義だなあ。
>スクリプト言語側にEval相当があれば実装できて当然 ってのはもしかして、...(略)...任意の(メタライブラリに準拠した)ライブラリをノーコーディングで呼べるようにする、という手順のことを、一言で「eval」と言っている、のですか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
敷居は低くなった? (スコア: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なのでしたよね。
とくれば、まあ普通の(良質な)スクリプト言語と同じくらいの
記述能力は有る
Re:敷居は低くなった? (スコア:2, 参考になる)
スクリプト言語へのインタフェースは、スクリプト言語側にEval相当があれば実装できて当然ですよね。でもそれは一対多の関係でしかないし、言語依存です。DOMはそのずるい(?)やり方を標準化してしまったわけだけど、これは置いといて。
「コンポー
Re:敷居は低くなった? (スコア:1)
あれれ?あーゆーものはevalだけで全部つくれると限らないような気がしましたが、
気のせいでしょうか?
evalだけではinterfaceの向こうの別世界(もしそれが別世界ならば)と
対話する術が無いですから。
>ここで言ってるコンポーネントってインタフェースによって言語非依存に再利用できるオブジェクトの事を言ってるんだから。
ふむ。じゃあ、その「クラス」ライブラリについて、特定言語だけを
その出自&供給先にしなければ、それで良いわけですよね。
じゃあ(ある意味で)
Re:敷居は低くなった? (スコア:1, 興味深い)
--
...よい子は早く寝ましょう。