パスワードを忘れた? アカウント作成
41977 story
プログラミング

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

ストーリー by hayakawa
個人的には歓迎(詳細情報待ちだけど) 部門より

ある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アーキテクチャのシステムとも連係可能になるそうだ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 自分の理解 (スコア:5, 参考になる)

    by Tsann (15931) on 2008年12月04日 16時10分 (#1467443)
    従来から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]へのリンクも。
    • by Anonymous Coward on 2008年12月04日 16時54分 (#1467478)
      私の理解も概ねそんな感じ。

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

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

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

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

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

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

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

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

      親コメント
      • Re:自分の理解 (スコア:3, すばらしい洞察)

        by Tsann (15931) on 2008年12月04日 17時57分 (#1467521)

        ただ判らないのは、なぜそんなものをいまさら導入したかってことだ。
        そこはタレコみ文にも書かれているCOMサポート関連ではないでしょうか?
        本来IDL or TLBがなければコンパイルできず、C#から扱うにはPIAなどが必要になりますが、
        dynamicの導入により、Guidさえあればコンパイルを完了させ、後は実行時に、とできるわけです。
        親コメント
        • つい最近私もExcelの拡張をVSTOで作ってみたりしたのですが

          ((Excel.Range)excel.Cells[1, 1]).Value2 = "Hello";
          と書かないといけないところを、C# 4.0 で

          excel.Cells[1, 1].Value = "Hello";
          にしたいというのは自然な要求だと思いました。
          親コメント
      • Re:自分の理解 (スコア:2, 参考になる)

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

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

        しかし、新たにC#に取り込まれたdynamicによって、恩恵に与る人が居る事も忘れないで欲しい。
        親コメント
      • 「お気楽な言語を使っている開発者」、たとえば JavaScript とか Perl とかのプログラマも、C#開発者として取り込みたいんじゃね?
        頭をC#用に切り替えなくてもいいですよ!ってことで。
        --
        # mishimaは本田透先生を熱烈に応援しています
        親コメント
      • Re:自分の理解 (スコア:1, すばらしい洞察)

        by Anonymous Coward on 2008年12月04日 17時28分 (#1467502)
        dynamic obj=IronPython.eval(pythoncode);
        MessageBox.Show(obj.some_str)
        obj.some_method("test");

        てな感じで、IronPythonとかIronRubyとかで定義されたクラスを
        そのまま使いたいんじゃないでしょうか。
        親コメント
      • by Anonymous Coward
        自分としては外部スクリプトとしてC#そのものを がっつり使えるってのが大きいかも。 今まではCODEDOMを使って実行時コンパイルまで はできたけど、その後で、普通にC#でやる事をGetTypeとか に解きほぐしてコーディングするのがきつかった。なんか、 せっかく高級言語を使っているのに、 やりたい事に自分でオブジェクト指向の低級操作に 解きほぐさなければいけなくて。 まあ確かにInteliSenseが文句を言わなかった時点で ほとんどコンパイルエラーが解消された事が保証される っていう利点がなくなってしまうのは、この場合仕方のないトレードオフでしょう。
      • by Anonymous Coward
        おおむね同意しますが、他言語やCOMとのインターフェースには動的バインディングがどうしても必要ですし、
        それをピリピリしながらリフレクションでやるよりも、dynamicを使って簡易に書けたほうが良いとは思います。

        Doutei嫌い(性的な意味で)のHejlsbergのことですから、実際のところダウンキャストくらいの安全性は持たせてるんじゃないですかね。
    • by s02222 (20350) on 2008年12月04日 18時30分 (#1467549)

      dynamic dynamic_obj = new Hoge();
      に対して、

      dynamic_obj.メソッド名(引数1,...,引数n);
      を自動的に、

      dynamic_obj.GetType()

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

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

      に書き換える恐怖のシンタックスシュガー、って事ですよね多分?
      親コメント
      • * COMオブジェクトだったら IDispatch 経由
          * IDynamicObject を実装してたら IDynamicObject 経由
          * そうじゃなかったらリフレクションから調べる
        という分岐を勝手に中でやるそうです。

        勝手にやられるのが恐怖っちゃー恐怖ですね。
        親コメント
        • by Tsann (15931) on 2008年12月04日 21時13分 (#1467656)
          そのメソッド呼び出しの戻り値は何らかの変数に格納されるわけですが、その時点で型キャストされ、また従来の静的バインドに戻ります。
          あくまでdynamic宣言した変数に対するメンバー呼び出しのみに制限されるので、それほど怖くないと思います。
          親コメント
      • by Anonymous Coward

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

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

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

      dual interfaceがどうの・・・
  • 個人的には・・・・・・ (スコア:2, おもしろおかしい)

    by arthor2005 (33291) on 2008年12月04日 14時44分 (#1467378)
    これ以上、ややこしい機能は追加しないでほしい。

    #未だにLINQを理解していない駄目駄目PGより
    • by Anonymous Coward
      まったくだ。
      言語使用はできるだけそのままに、フレームワークだけアップグレードして欲しい。
  • 「動的言語」って言われるとコードの自己修正が可能なように思えるんだけど。
    • by Anonymous Coward on 2008年12月04日 15時55分 (#1467433)
      コロコロと仕様が変更される言語。
      親コメント
      • by Anonymous Coward
        「Douteki」言語だから、略してD言語ですね!



        あれ?
        • by Anonymous Coward
          Dynamicでいいじゃない
          • by Anonymous Coward
            >Dynamicでいいじゃない

            それだとカッコ良く聞こえて面白くない。
      • by Anonymous Coward
        C#から更に半音上がってDですな
    • by Anonymous Coward
      英語力に自信ないけど、コンパイルせずにソースファイルのまま実行できる、と言う意味での
      動的言語と解釈しました。
  • C#4.0の仕様がどうなるかは具体的に分かりませんけれども、言語として自由度が高くなる
    程、いい言語だと個人的に思っています。
    制約や、「これはこう書かないと駄目だ」とかいうのは、人がプログラミング言語に合わせない
    といけないと言う意味では、服に自分の体を合わせないといけないような感じで、窮屈だと思って
    います。勿論、「驚き最小の原理」は出来る限り守るべきですが、これを強制ではなく、個人の
    自由にすればいいと。チームで作業するならば、チーム内でルールを決めればいいわけです。
    以上の個人的見解の立場から、C#も進化するのはいいことだと思います。
    (C++でさえ、新しく進化しようとしているのだから、いいじゃないですか。)
    • by Anonymous Coward on 2008年12月04日 21時45分 (#1467680)
      たぶん頭のいい人、かつ、頭の並みな人と一緒に仕事をしたことが無い人なんだと思います。

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

      服の喩えでは、TPOに応じて服を選ぶのと一緒です。
      Tシャツジーンズは色々万能かもしれませんが、合コンで許されるのはイケメン限定ですよね。
      世の中、あなたほどのイケメンはなかなかいないのです。
      そして、あなたがいくらイケメンでも、あなたの同僚か上司か部下はおそらくフツメン以下なのです。
      親コメント
      • >なんでもできる言語は、並み人は何をしたらいいのか判らないか、迷ってしまって効率が悪いのです。

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

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

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

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

          親コメント
        • by Anonymous Coward
          もとの人じゃないけど

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

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

          じゃないかな?

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

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

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

          コンパイラの方がはるかに賢くて、いつも叱られているけど、それから逃れられないドMのAC
      • Tシャツジーンズはあるあるネタとして面白いが、喩えとしてはよく分からないな。

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

        現実的にこういう人はまずいない。
        よく居るのは他人の理解度なんて気にもしない人だろうな。(10代に多そうだ)
        一匹狼で一人で何でもやるならともかく、本当に頭のいい人は自分を含めたチームとか会社がどれだけ高いパフォーマンスを出せるか、というのは考えるものだろう。
        親コメント
    • by Anonymous Coward
      チャーチルの
      「二十歳までに共産主義にかぶれない者は情熱が足りないが、二十歳を過ぎて共産主義にかぶれている者は知能が足りない」
      という言葉を連想しました:)

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

      これが窮屈で

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

      これが窮屈でないと考える思考回路が理解できません。
      逆じゃない?
      • by Anonymous Coward
        #それはチャーチルの言葉じゃないってツッコミはさておき

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

        コンパイラとか実行環境レベルでこの機能をon/off出来るような仕様だと嬉しいかなあ...(運用ルールを徹底させるのが楽という意味で)。
        • by Anonymous Coward
          > 言語レベルで窮屈な仕様を切るのではなく、自由度の高い仕様にしておいて、利用者(プログラマ)が利用時に自主的に運用ルールを決めるようにしたほうが良くね? って話でしょう。

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

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

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

            --
            LIVE-GON(リベゴン)
            親コメント
  • by Anonymous Coward on 2008年12月04日 14時42分 (#1467375)
    「動的言語機能を使わない」なんてTIPSが載るようになったりして。

    動的な機能が使えるのは、それは既に動的型言語だと思う。
    静的型言語を途中で動的型言語に仕様変更するなんてMSらしいと言えば言えるのだが、
    プログラマーとしてはそれに関わりたいとは思わんな。
    • by Anonymous Coward
      動的な型も、静的な型も扱える言語になるんだと思う。
      基本は静的な型で利用し、ある部分で動的に型を利用できた方が便利だというところでそれが利用できるなら、それはそれで便利だよね。
      使いたくなきゃ、使わなければいい話なので。

      もっとも、初心者が使わなくてもいいのにバリバリに使ってスパゲッティ化させるという問題もあるのだが。
      まあ、C# はもともと初心者向けというより現場向けな言語だと感じているのでどーでもいいか。
  • by Anonymous Coward on 2008年12月04日 14時43分 (#1467376)
    ずっと「次回作にご期待下さい!」ばっかだな。
    もうちょっと落ち着いて考えたら?
    • by Anonymous Coward
      消費主義の社会は完璧な商品でなくても成立します。
  • by Anonymous Coward on 2008年12月04日 18時56分 (#1467570)
    このままずっとぶくぶくと仕様を追加していくつもりなんだろうか。 今でさえ、決して小さくはないと思うのだけど。
    • by TarZ (28055) on 2008年12月04日 19時15分 (#1467582) 日記
      ヘルスバーグ氏にまだ色々アイディアがあるようなので、今後も仕様拡張は続くのではないでしょうか。

      今のところ、互換性を維持する方向での拡張が続いているので、あんまり気にする必要はないと思います。
      別に、すべての言語仕様を覚えてなければプログラミングできないわけでもないですし。
      親コメント
    • by Anonymous Coward on 2008年12月04日 19時23分 (#1467588)
      ヘルスバーグに見捨てられたDel厨としては、DelphiにはあったのにC#になって消えたものは出来るだけ追加して欲しい・・・
      親コメント
      • by 130R (31126) on 2008年12月05日 11時57分 (#1467963) 日記

        begin
        end;
        ですね!

        #ほかなんかあったっけ
        親コメント
      • by Anonymous Coward
        implements指令が欲しいです。
        propertyの宣言方法もDelphiのほうが好み。
        • by argon (3541) on 2008年12月06日 1時30分 (#1468477) 日記
          いわゆる 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 の記法のなんともダサいのが残念に思っています。
          親コメント
typodupeerror

犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー

読み込み中...