アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
あのぅ、すいませぇん (スコア:1, 興味深い)
# 類似品がすでにあるから無視?
Re:あのぅ、すいませぇん (スコア:3, 興味深い)
Perl 対応はメリットが少ないんじゃないですかね。
PHP ならWebブラウザというGUIがありますし、
Ruby には Ruby/Qt という手がありますが、
Perl でGUIって… Perl/Tk?
私はとりあえず、Delphi for PHP が AJAX をサポートしている、という点が気になってます。
これについてはあまり情報が出てないのですが、
・AJAX による動的操作が可能なコンポーネントが用意されてるだけで、コード記述はPHP側のみ
・JavaScript によるコード記述が可能(VCL for JavaScript?)
のどちらなんですかね。
私はPHP嫌いなのですが、VCL for JavaScript なんてのが出るなら、Delphi for PHP を買ってもいいかも…
Re:あのぅ、すいませぇん (スコア:0)
>Perl 対応はメリットが少ないんじゃないですかね。
>PHP ならWebブラウザというGUIがありますし、
>Ruby には Ruby/Qt という手がありますが、
>Perl でGUIって… Perl/Tk?
1行目はその通りと思いますが、それが2行目以降とどう繋がるのかよく判りません。
Delphi(のようなもの)を作るのだとして、それは別に、
該当言語の「既存の」GUIライブラリバインディングを
ベースにする必要が有るわけではないです。
というか、Rubyも(あと他の言語もよく知りませんがおそらく)
色々なGUIライブラリとのバインディングライブラリが
後から色々作られていってた(る)わけで、
そこに今回Delphiが新たに参入する、というだけのことだと「思います」。
つまりRuby/TkやFXRubyなどなどの兄弟の1つとしてRuby/VCLが出現する。
ああ。もちろんこれはあくまで想像でしかないので、
実際に本当にRubyの「既存の」GUIライブラリを使ってDelphiが作られる
かも知れませんが、あくまでどちらも「かもしれない」だけです。
もともとVCL(元祖)は、結果はともかく恐らく設計理念としては、
Windowsべったりという代物ではなかったです。
(MFCやVBのような)単なる薄いラッパーではなく、
WindowHandleの不便な点を色々回避してくれて、
より楽に扱えるプログラムモデルを提供してくれる、
一段ハイレベルなライブラリでした。
察するにVCLとは「考え方」なんでしょう。
で、今回もたぶん、RubyやPHPに、
VCLの「考え方」に基づいたライブラリが「移植」される/た、
ということなんじゃないかと想像します。
同じように、もしCodeGearの気が向けば、
PerlにVCLを「移植」する、ということも
原理的には有り得るでしょう。
そして、それが「メリットが少ない」とは思いません。
もっともPerlユーザがみんなVB/Delphi的 GUI RADを毛嫌いしてたりするのだとすれば話は別ですが:-)、まさかねえ?
ーーー
ところで。私は最近VisualStudio2005を触り始めたのですが、
Delphiと比べて「退化」してるのに愕然としてるところです。
というのは、ソース自動生成をしすぎるんですよね。
いったんソースという形でバラバラにオブジェクトの属性の設定とかをしちゃうと、
恐らく、あとで属性を(GUI RADレベルで)変更しようとしたとき、
取りこぼしが生じるんでしょう。
無造作にGUI部品を「はがしたり」すると、たちどころにコンパイルエラーが出まくります。
うっとうしい!
こういうHELLに対抗するためには、以下のいずれか(両方ももちろん良し)をすべきだと考えます。
1:ソースを出来るだけ生成せず、オブジェクト定義は別データ(ファイル)にしておき、
それを起動時にロードすることで動的にオブジェクトを構築する、
というシステムにする。
2:DuckTyping。型について言語側は細かいことを言わない。
メソッドの実行時自動生成(ソース字面は一度も人間の目に触れない)もRailsのように多用する。
元祖Delphiは2は(Pascalなので)無理ですが1は実現していました。
ソース自動生成な部分は最低限に抑え、あとは出来るだけデータを元に起動時に動的に構築する。
その仕組みのおかげで、「そのオブジェクト自体が」データのロードのタイミングを制御するという技も使えたので、
VSのようにドツボにはまることは有りませんでした。
Delphi For 動的言語ならば、1だけでなく2も駆使できることでしょう。
かなり未来は有望なのではないかと思います。
(といっても、これは動的言語とGUI RADの相性の話であって、Delphiというブランドだけのアドバンテージではないですが。
なお、1で別ファイルといいましたが、XMLなどにする「必要」はないです。
YAMLでもいいですし、JSONやLisp(S式)などのようにその言語自体をデータ構造保存形式として流用することもOKでしょう。
C#の自動生成ソースはいわゆる「ソース」の形をし過ぎているので駄目ですが、
リストやハッシュをリテラルでさくさく書ける(しかも型なしなのでリテラルの中で型をいちいち心配しなくていい)言語は
それをそのままデータフォーマットにしても厄介なことにならない。