アカウント名:
パスワード:
var sample1 = new Sample();sample1.Add();dynamic sample2 = new Sample();sample2.Add();
ただ判らないのは、なぜそんなものをいまさら導入したかってことだ。
((Excel.Range)excel.Cells[1, 1]).Value2 = "Hello";
excel.Cells[1, 1].Value = "Hello";
dynamic dynamic_obj = new Hoge();
dynamic_obj.メソッド名(引数1,...,引数n);
dynamic_obj.GetType() .GetMethod("メソッド名",{引数1.GetType(),...,引数n.GetType()}) .Invoke(引数1,...,引数n);
dynamic_obj.GetType()
.GetMethod("メソッド名",{引数1.GetType(),...,引数n.GetType()})
.Invoke(引数1,...,引数n);
に書き換える恐怖のシンタックスシュガー、って事ですよね多分?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
自分の理解 (スコア:5, 参考になる)
正確にはそれを支えるために.NET Framework 4.0では動的なメソッド呼び出しをサポートするインターフェースが用意されるとか。
コード中には静的にコンパイルされたものと動的に決定されるものとが混在できる仕様です。
例えばあるSampleクラスがAdd()メソッドを持っていた場合、C# 4.0では と書けます。sample1はSampleクラスで確定しますがsample2は動的呼び出しを行うインスタンスになり、Add()呼び出しも"Add"という名前を持つメソッドを実行時に探して呼び出すようにコンパイルされます。
ちなみに本家C# Future [microsoft.com]へのリンクも。
Re:自分の理解 (スコア:2, 興味深い)
ただ判らないのは、なぜそんなものをいまさら導入したかってことだ。
動的言語の「お気楽さ」は便利だけど、バグの素だったりメンテしにくかった
り色々欠点がある。C#で書くようなアプリの場合に、「お気楽さ」のメリット
と「バグの素」のデメリットを比べたらどうだろうか?
その「お気楽さ」だって、「えーと、ここはdynamicを使えば楽に書けるかな?」
と、静的に書くところと動的に書くところの使い分けをいちいち考えながらコー
ディングする必要があるんだから、言うほどお気楽なわけでもない。
導入メリットが見えないんだよね。上の例も、dynamicである必然性が無いし、
メリットのある例ってどこかにあるのかな。
リフレクションを使えばできることをカジュアルにできるようにするなんて、
大反対。リフレクションなんてそもそもバグの素で、プロジェクトの中でも熟
練したコアチームプログラマが細心のレビューを重ねて使用するものだ。
dynamicなんて一言で書けるようにすると、経験の浅いプログラマが気軽に書
き散らしてプログラムのそこら中に動的バインディングが散らばってひどいこ
とになるのは必定。冷静なプロジェクト管理者だったら、原則使用禁止にする
はず。
で、本当に使用するべきケースの使用頻度が低いんなら、リフレクションで十
分だよね。少しぐらいタイプ量が増えたって関係ない。
・・・と思っているんだが、これに対してdynamic導入の正当性の説得力の
ある解説をキボン。
Re:自分の理解 (スコア:3, すばらしい洞察)
本来IDL or TLBがなければコンパイルできず、C#から扱うにはPIAなどが必要になりますが、
dynamicの導入により、Guidさえあればコンパイルを完了させ、後は実行時に、とできるわけです。
Re:自分の理解 (スコア:1)
Re:自分の理解 (スコア:2, 参考になる)
ネイティブ混在(C++/CLI)~動的言語/スクリプト(DLR)
・近年、動的言語やDLRの重要度が高まり、C#にもそれらとの連携が求められている。
・現状ではレイトバインディングをやるのにリフレクションを駆使する事になる。
(やった事がある人は分かると思うけど、凄く面倒で保守性も悪い。)
dynamicにメリットを見出せない人は、使用を禁止すればいい。
C#4.0からも従来通りの静的言語として使い続ける事ができる。
しかし、新たにC#に取り込まれたdynamicによって、恩恵に与る人が居る事も忘れないで欲しい。
Re:自分の理解 (スコア:1)
頭をC#用に切り替えなくてもいいですよ!ってことで。
# mishimaは本田透先生を熱烈に応援しています
Re:自分の理解 (スコア:1, すばらしい洞察)
MessageBox.Show(obj.some_str)
obj.some_method("test");
てな感じで、IronPythonとかIronRubyとかで定義されたクラスを
そのまま使いたいんじゃないでしょうか。
Re: (スコア:0)
Re: (スコア:0)
それをピリピリしながらリフレクションでやるよりも、dynamicを使って簡易に書けたほうが良いとは思います。
Doutei嫌い(性的な意味で)のHejlsbergのことですから、実際のところダウンキャストくらいの安全性は持たせてるんじゃないですかね。
Re:自分の理解 (スコア:2, 興味深い)
Re:自分の理解 (スコア:1)
* IDynamicObject を実装してたら IDynamicObject 経由
* そうじゃなかったらリフレクションから調べる
という分岐を勝手に中でやるそうです。
勝手にやられるのが恐怖っちゃー恐怖ですね。
Re:自分の理解 (スコア:1)
あくまでdynamic宣言した変数に対するメンバー呼び出しのみに制限されるので、それほど怖くないと思います。
Re: (スコア:0)
つまり、C#コンパイラの仕事は、「dynamic_obj.メソッド名(引数1,...,引数n)」をそのまま素直にASTに変換すること。
言語エンジンは渡されたASTと引数の実行時型を使って動的バインディングを行い、実行時コード生成を利用してJIT可能コードに変換、結果はデリゲートに格納、格納されたデリゲートは引数の実行時型をキーとしてキャッシュ、というかなりパフォーマンス重視の本格的な実装だったような気がするけど、うろ覚えなんであんまり自信がない。
猛烈な既視感 (スコア:0)
あらかじめ型が決まっているほうが早いとかなんとか・・・
dual interfaceがどうの・・・