C# 4.0は「動的言語」にもなる

あるAnonymous Coward 曰く、

The Registerの記事によると、先日開催されたMicrosoftのProfessional Developers' Conference（PDC）にてC#アーキテクトのAnders Hejlsberg氏が語ったところによると、C#の次期バージョンであるC# 4.0は動的言語としても利用可能になるそうだ。

すでに.NET FrameworkとしてはVB.NETやIronPython、IronRubyが利用できるので、C#の動的言語化はそれほど突飛なアイデアではないのかもしれない。なお、C# 4.0ではCOM IDispatchインタフェースがサポートされ、COMアーキテクチャのシステムとも連係可能になるそうだ。

自分の理解

[Tsann (15931)]

従来からTypeクラスとMemberInfoクラスを使うことで動的なメソッド呼び出しは可能でしたが、C# 4.0では言語レベルでそれがサポートされるという意味です。
正確にはそれを支えるために.NET Framework 4.0では動的なメソッド呼び出しをサポートするインターフェースが用意されるとか。

コード中には静的にコンパイルされたものと動的に決定されるものとが混在できる仕様です。
例えばあるSampleクラスがAdd()メソッドを持っていた場合、C# 4.0では

var sample1 = new Sample();
sample1.Add();
dynamic sample2 = new Sample();
sample2.Add();

と書けます。sample1はSampleクラスで確定しますがsample2は動的呼び出しを行うインスタンスになり、Add()呼び出しも"Add"という名前を持つメソッドを実行時に探して呼び出すようにコンパイルされます。

ちなみに本家C# Future [microsoft.com]へのリンクも。

Re:自分の理解

[Anonymous Coward]

私の理解も概ねそんな感じ。

ただ判らないのは、なぜそんなものをいまさら導入したかってことだ。

動的言語の「お気楽さ」は便利だけど、バグの素だったりメンテしにくかった
り色々欠点がある。C#で書くようなアプリの場合に、「お気楽さ」のメリット
と「バグの素」のデメリットを比べたらどうだろうか？

その「お気楽さ」だって、「えーと、ここはdynamicを使えば楽に書けるかな？」
と、静的に書くところと動的に書くところの使い分けをいちいち考えながらコー
ディングする必要があるんだから、言うほどお気楽なわけでもない。

導入メリットが見えないんだよね。上の例も、dynamicである必然性が無いし、
メリットのある例ってどこかにあるのかな。

リフレクションを使えばできることをカジュアルにできるようにするなんて、
大反対。リフレクションなんてそもそもバグの素で、プロジェクトの中でも熟
練したコアチームプログラマが細心のレビューを重ねて使用するものだ。

dynamicなんて一言で書けるようにすると、経験の浅いプログラマが気軽に書
き散らしてプログラムのそこら中に動的バインディングが散らばってひどいこ
とになるのは必定。冷静なプロジェクト管理者だったら、原則使用禁止にする
はず。

で、本当に使用するべきケースの使用頻度が低いんなら、リフレクションで十
分だよね。少しぐらいタイプ量が増えたって関係ない。

・・・と思っているんだが、これに対してdynamic導入の正当性の説得力の
ある解説をキボン。

Re:自分の理解

[Tsann (15931)]

ただ判らないのは、なぜそんなものをいまさら導入したかってことだ。

そこはタレコみ文にも書かれているCOMサポート関連ではないでしょうか？
本来IDL or TLBがなければコンパイルできず、C#から扱うにはPIAなどが必要になりますが、
dynamicの導入により、Guidさえあればコンパイルを完了させ、後は実行時に、とできるわけです。

Re:自分の理解

[kamiyan (10895)]

つい最近私もExcelの拡張をVSTOで作ってみたりしたのですが

((Excel.Range)excel.Cells[1, 1]).Value2 = "Hello";

と書かないといけないところを、C# 4.0 で

excel.Cells[1, 1].Value = "Hello";

にしたいというのは自然な要求だと思いました。

Re:自分の理解

[Anonymous Coward]

・C#は強力な糊言語である。
　ネイティブ混在（C++/CLI）～動的言語/スクリプト（DLR）
・近年、動的言語やDLRの重要度が高まり、C#にもそれらとの連携が求められている。
・現状ではレイトバインディングをやるのにリフレクションを駆使する事になる。
　（やった事がある人は分かると思うけど、凄く面倒で保守性も悪い。）

dynamicにメリットを見出せない人は、使用を禁止すればいい。
C#4.0からも従来通りの静的言語として使い続ける事ができる。

しかし、新たにC#に取り込まれたdynamicによって、恩恵に与る人が居る事も忘れないで欲しい。

Re:自分の理解

[mishima (737)]

「お気楽な言語を使っている開発者」、たとえば JavaScript とか Perl とかのプログラマも、C#開発者として取り込みたいんじゃね？
頭をC#用に切り替えなくてもいいですよ！ってことで。

--
# mishimaは本田透先生を熱烈に応援しています

Re:自分の理解

[Anonymous Coward]

dynamic obj=IronPython.eval(pythoncode);
MessageBox.Show(obj.some_str)
obj.some_method("test");

てな感じで、IronPythonとかIronRubyとかで定義されたクラスを
そのまま使いたいんじゃないでしょうか。

Re:

[Anonymous Coward]

自分としては外部スクリプトとしてC#そのものを がっつり使えるってのが大きいかも。 今まではCODEDOMを使って実行時コンパイルまで はできたけど、その後で、普通にC#でやる事をGetTypeとか に解きほぐしてコーディングするのがきつかった。なんか、 せっかく高級言語を使っているのに、 やりたい事に自分でオブジェクト指向の低級操作に 解きほぐさなければいけなくて。 まあ確かにInteliSenseが文句を言わなかった時点で ほとんどコンパイルエラーが解消された事が保証される っていう利点がなくなってしまうのは、この場合仕方のないトレードオフでしょう。

Re:

[Anonymous Coward]

おおむね同意しますが、他言語やCOMとのインターフェースには動的バインディングがどうしても必要ですし、
それをピリピリしながらリフレクションでやるよりも、dynamicを使って簡易に書けたほうが良いとは思います。

Doutei嫌い(性的な意味で)のHejlsbergのことですから、実際のところダウンキャストくらいの安全性は持たせてるんじゃないですかね。

Re:自分の理解

[s02222 (20350)]

dynamic dynamic_obj = new Hoge();

に対して、

dynamic_obj.メソッド名(引数1,...,引数n);

を自動的に、

dynamic_obj.GetType()

.GetMethod("メソッド名",{引数1.GetType(),...,引数n.GetType()})

.Invoke(引数1,...,引数n);

に書き換える恐怖のシンタックスシュガー、って事ですよね多分?

Re:自分の理解

[kamiyan (10895)]

* COMオブジェクトだったら IDispatch 経由
  * IDynamicObject を実装してたら IDynamicObject 経由
  * そうじゃなかったらリフレクションから調べる
という分岐を勝手に中でやるそうです。

勝手にやられるのが恐怖っちゃー恐怖ですね。

Re:自分の理解

[Tsann (15931)]

そのメソッド呼び出しの戻り値は何らかの変数に格納されるわけですが、その時点で型キャストされ、また従来の静的バインドに戻ります。
あくまでdynamic宣言した変数に対するメンバー呼び出しのみに制限されるので、それほど怖くないと思います。

Re:

[Anonymous Coward]

に書き換える恐怖のシンタックスシュガー、って事ですよね多分?

違ったような。コンパイル時にASTに変換して、それを実行時に言語エンジンへ投げ込むような設計だったはず。
つまり、C#コンパイラの仕事は、「dynamic_obj.メソッド名(引数1,...,引数n)」をそのまま素直にASTに変換すること。

言語エンジンは渡されたASTと引数の実行時型を使って動的バインディングを行い、実行時コード生成を利用してJIT可能コードに変換、結果はデリゲートに格納、格納されたデリゲートは引数の実行時型をキーとしてキャッシュ、というかなりパフォーマンス重視の本格的な実装だったような気がするけど、うろ覚えなんであんまり自信がない。

猛烈な既視感

[Anonymous Coward]

VBからActiveXコントロールを使うっていう場面で、似たような話を見たような・・・

あらかじめ型が決まっているほうが早いとかなんとか・・・

dual interfaceがどうの・・・

個人的には･･････

[arthor2005 (33291)]

これ以上、ややこしい機能は追加しないでほしい。

#未だにLINQを理解していない駄目駄目PGより

Re:

[Anonymous Coward]

まったくだ。
言語使用はできるだけそのままに、フレームワークだけアップグレードして欲しい。

それは「動的型付け言語」ってこと？

[tarosuke (2403)]

「動的言語」って言われるとコードの自己修正が可能なように思えるんだけど。

Re:それは「動的型付け言語」ってこと？

[Anonymous Coward]

コロコロと仕様が変更される言語。

Re:

[Anonymous Coward]

「Douteki」言語だから、略してD言語ですね！



あれ?

Re:

[Anonymous Coward]

Dynamicでいいじゃない

Re:

[Anonymous Coward]

＞Dynamicでいいじゃない

それだとカッコ良く聞こえて面白くない。

Re:

[Anonymous Coward]

じゃあDynamiqueで

Re:

[Anonymous Coward]

C#から更に半音上がってDですな

Re:

[Anonymous Coward]

英語力に自信ないけど、コンパイルせずにソースファイルのまま実行できる、と言う意味での
動的言語と解釈しました。

自由度が高くなるのはいいことだと思ってます。

[taro-nishino (32033)]

C#4.0の仕様がどうなるかは具体的に分かりませんけれども、言語として自由度が高くなる
程、いい言語だと個人的に思っています。
制約や、「これはこう書かないと駄目だ」とかいうのは、人がプログラミング言語に合わせない
といけないと言う意味では、服に自分の体を合わせないといけないような感じで、窮屈だと思って
います。勿論、「驚き最小の原理」は出来る限り守るべきですが、これを強制ではなく、個人の
自由にすればいいと。チームで作業するならば、チーム内でルールを決めればいいわけです。
以上の個人的見解の立場から、C#も進化するのはいいことだと思います。
（C++でさえ、新しく進化しようとしているのだから、いいじゃないですか。）

Re:自由度が高くなるのはいいことだと思ってます。

[Anonymous Coward]

たぶん頭のいい人、かつ、頭の並みな人と一緒に仕事をしたことが無い人なんだと思います。

実社会でいい言語とは、目的を果たす記述が簡単にできて、余計なことができない言語です。
なんでもできる言語は、並み人は何をしたらいいのか判らないか、迷ってしまって効率が悪いのです。
世の中に色々な言語があるのはそれなりに必要性があるからなわけで。

服の喩えでは、TPOに応じて服を選ぶのと一緒です。
Ｔシャツジーンズは色々万能かもしれませんが、合コンで許されるのはイケメン限定ですよね。
世の中、あなたほどのイケメンはなかなかいないのです。
そして、あなたがいくらイケメンでも、あなたの同僚か上司か部下はおそらくフツメン以下なのです。

Re:自由度が高くなるのはいいことだと思ってます。

[kabuchan (37144)]

>なんでもできる言語は、並み人は何をしたらいいのか判らないか、迷ってしまって効率が悪いのです。

並みの人は迷いません、最初に動いたもので実装してしまう。
何種類か方法があっても、それぞれの検証もせずに…

でもこれは、Cでもアセンブリでも言える事、言語仕様は関係ないな

Re:自由度が高くなるのはいいことだと思ってます。

[21 (23614)]

> たぶん頭のいい人、かつ、頭の並みな人と一緒に仕事をしたことが無い人なんだと思います。

「かつ」が「且つ」だとするとよく解らないので、
「もしくは」の間違いじゃないでしょうか。

Re:自由度が高くなるのはいいことだと思ってます。

[Stealth (5277)]

この文脈だと素直に「たぶん頭のいい人で、頭の並な人と～」の方がわかりやすいでしょう。(かつ、はあっても無くてもいい)
# そうじゃないと、後半でイケメン扱いしているのとバランスが取れません。

Re:

[Anonymous Coward]

もとの人じゃないけど

> たぶん頭のいい人、かつ、頭の並みな人と一緒に仕事をしたことが無い人なんだと思います。

（あなたは頭のいい人） && （あなたは頭の並みな人と一緒に仕事をしたことが無い人）

じゃないかな？

（私は頭の悪い人） && （私はそんな私より仕事のできない人ばかりと仕事をしている人）

なのでもとのコメントには激しく同意です。

動的言語は頭のいい人のための言語だと思いますよ。

コンパイラの方がはるかに賢くて、いつも叱られているけど、それから逃れられないドMのAC

Re:自由度が高くなるのはいいことだと思ってます。

[21 (23614)]

なるほど！
あなたは、を読みきれませんでした。お恥ずかしい。

Re:自由度が高くなるのはいいことだと思ってます。

[sanbon (24823)]

Ｔシャツジーンズはあるあるネタとして面白いが、喩えとしてはよく分からないな。

> たぶん頭のいい人、かつ、頭の並みな人と一緒に仕事をしたことが無い人なんだと思います。

現実的にこういう人はまずいない。
よく居るのは他人の理解度なんて気にもしない人だろうな。(10代に多そうだ)
一匹狼で一人で何でもやるならともかく、本当に頭のいい人は自分を含めたチームとか会社がどれだけ高いパフォーマンスを出せるか、というのは考えるものだろう。

Re:

[Anonymous Coward]

チャーチルの
「二十歳までに共産主義にかぶれない者は情熱が足りないが、二十歳を過ぎて共産主義にかぶれている者は知能が足りない」
という言葉を連想しました:)

> 服に自分の体を合わせないといけないような感じで、

これが窮屈で

> チーム内でルールを決めればいいわけです。

これが窮屈でないと考える思考回路が理解できません。
逆じゃない？

Re:

[Anonymous Coward]

#それはチャーチルの言葉じゃないってツッコミはさておき

言語レベルで窮屈な仕様を切るのではなく、自由度の高い仕様にしておいて、利用者（プログラマ）が利用時に自主的に運用ルールを決めるようにしたほうが良くね? って話でしょう。

コンパイラとか実行環境レベルでこの機能をon/off出来るような仕様だと嬉しいかなあ...（運用ルールを徹底させるのが楽という意味で）。

Re:

[Anonymous Coward]

> 言語レベルで窮屈な仕様を切るのではなく、自由度の高い仕様にしておいて、利用者（プログラマ）が利用時に自主的に運用ルールを決めるようにしたほうが良くね? って話でしょう。

利用者が自主的にルールを決めてもロクなことにならないから、言語仕様で厳しくチェックされる言語があるんじゃね？という話です。
少なくとも静的型付けは40年以上の歴史がありますし、有用性は十分立証されていると言えるでしょう。

# 元コメは情熱的ですね

Re:自由度が高くなるのはいいことだと思ってます。

[live-gon (30327)]

利用者が自主的にルールを決めてもロクなことにならないから、言語仕様で厳しくチェックされる言語があるんじゃね？という話です。 少なくとも静的型付けは40年以上の歴史がありますし、有用性は十分立証されていると言えるでしょう。

動的型付けも出来るけど静的型付けのほうが有用だよね、という歴史なのかどうか、ちょっと微妙なところです。有用なのを否定しているわけじゃないですが、本当に言語としての選択の結果としての静的型付けだったのかなあと（実行速度やデバッグ、その他の周辺も言語仕様の有用性ってことで譲るとしてもなお）。

--
LIVE-GON(リベゴン)

Effective C#

[Anonymous Coward]

「動的言語機能を使わない」なんてTIPSが載るようになったりして。

動的な機能が使えるのは、それは既に動的型言語だと思う。
静的型言語を途中で動的型言語に仕様変更するなんてMSらしいと言えば言えるのだが、
プログラマーとしてはそれに関わりたいとは思わんな。

Re:

[Anonymous Coward]

動的な型も、静的な型も扱える言語になるんだと思う。
基本は静的な型で利用し、ある部分で動的に型を利用できた方が便利だというところでそれが利用できるなら、それはそれで便利だよね。
使いたくなきゃ、使わなければいい話なので。

もっとも、初心者が使わなくてもいいのにバリバリに使ってスパゲッティ化させるという問題もあるのだが。
まあ、C# はもともと初心者向けというより現場向けな言語だと感じているのでどーでもいいか。

なんつーか

[Anonymous Coward]

ずっと「次回作にご期待下さい！」ばっかだな。
もうちょっと落ち着いて考えたら？

Re:

[Anonymous Coward]

消費主義の社会は完璧な商品でなくても成立します。

C#言語の行方

[Anonymous Coward]

このままずっとぶくぶくと仕様を追加していくつもりなんだろうか。 今でさえ、決して小さくはないと思うのだけど。

Re:C#言語の行方

[TarZ (28055)]

ヘルスバーグ氏にまだ色々アイディアがあるようなので、今後も仕様拡張は続くのではないでしょうか。

今のところ、互換性を維持する方向での拡張が続いているので、あんまり気にする必要はないと思います。
別に、すべての言語仕様を覚えてなければプログラミングできないわけでもないですし。

Re:C#言語の行方

[Anonymous Coward]

＞別に、すべての言語仕様を覚えてなければプログラミングできないわけでもないですし。

でも、他人のコードを読むためには・・・

ピコーン

[Anonymous Coward]

そうだ！
読まずに書き直せばいいんだよ！

Re:ピコーン

[cactus (20557)]

次の日、自分のコードもすべて書き直すわけですね。

Re:C#言語の行方

[Anonymous Coward]

ヘルスバーグに見捨てられたDel厨としては、DelphiにはあったのにC#になって消えたものは出来るだけ追加して欲しい・・・

Re:C#言語の行方

[130R (31126)]

begin
end;

ですね！

#ほかなんかあったっけ

Re:

[Anonymous Coward]

implements指令が欲しいです。
propertyの宣言方法もDelphiのほうが好み。

Re:C#言語の行方

[argon (3541)]

いわゆる property の記法は、Ruby のそれが一番好みです。
private member object である @prop を使う method は以下のように書きます。

class Foo
    def prop
        @prop
    end
    def prop=v
        @prop=v
    end
end

foo = Foo.new
foo.prop = 123
print foo.prop

method name の末尾に "=" をつけることで setter になるというのがしびれます。
なお、上記と同様に定義して使う場合、簡単に書ける method が用意されています。

class Foo
    attr_accessor :prop
end

C# については、 LINQ や dynamic がイケてるだけに、
get put の記法のなんともダサいのが残念に思っています。

Re:C#言語の行方

[Tsann (15931)]

lambda式ならC# 3.0で導入済みですよ。
もっと言えば書式はあまりきれいではありませんが、匿名メソッドも関数内関数で、こちらはC# 2.0からあります。