パラメータ名の反映：C＃ラムダ式の乱用または構文の優秀さ？

私はMvcContribグリッドコンポーネントを見て、グリッド構文で使用されている構文トリックに魅了されましたが、同時に反発しました。

.Attributes(style => "width:100%")

上記の構文は、生成されたHTMLのスタイル属性をに設定しwidth:100%ます。注意を払えば、「スタイル」はどこにも指定されていません。式内のパラメーターの名前から推定されます！私はこれを掘り下げる必要があり、「魔法」が発生する場所を見つけました：

Hash(params Func<object, TValue>[] hash)
{
    foreach (var func in hash)
    {
        Add(func.Method.GetParameters()[0].Name, func(null));
    }
}

したがって、実際には、コードは正式なコンパイル時のパラメータ名を使用して、属性の名前と値のペアのディクショナリを作成しています。結果として得られる構文構成は実際に非常に表現力豊かですが、同時に非常に危険です。

ラムダ式の一般的な使用では、副作用なしで使用される名前の置換が可能です。私が言う本の中の例を参照してくださいcollection.ForEach(book => Fire.Burn(book))私は私のコードで書くことができます知っているcollection.ForEach(log => Fire.Burn(log))と、それは同じことを意味します。しかし、ここでMvcContribグリッド構文を使用すると、突然、変数に選択した名前に基づいて積極的に調べて決定を行うコードが見つかります。

それで、C＃3.5 / 4.0コミュニティとラムダ式愛好家とのこの一般的な習慣はありますか？または、私が心配する必要のない不正な1つのトリックマーベリックですか？

これは相互運用が不十分です。たとえば、次のC＃-F＃の例を考えてみます。

C＃：

public class Class1
{
    public static void Foo(Func<object, string> f)
    {
        Console.WriteLine(f.Method.GetParameters()[0].Name);
    }
}

F＃：

Class1.Foo(fun yadda -> "hello")

結果：

「arg」が出力されます（「yadda」ではありません）。

その結果、ライブラリの設計者は、.Net言語間で適切な相互運用性を確保したい場合は、この種の「乱用」を回避するか、少なくとも「標準」のオーバーロード（たとえば、文字列名を追加パラメーターとして受け取る）を提供する必要があります。

私はその名前のせいでそれほど奇妙なのではなく、ラムダが不要であることを発見しました。匿名型を使用してより柔軟にすることができます：

.Attributes(new { style = "width:100%", @class="foo", blip=123 });

これは（たとえば）ASP.NET MVCの多くで使用されるパターンであり、他の用途もあります（警告、名前が呼び出し元固有ではなく魔法の値である場合のAyendeの考えにも注意してください）

私の意見を投げたかっただけです（私はMvcContribグリッドコンポーネントの作成者です）。

これは間違いなく言語の乱用です-それについては間違いありません。ただし、私はそれを直感に反するものとは考えていませんAttributes(style => "width:100%", @class => "foo")
。インテリセンスの観点から、私はそれがかなり不透明であることに同意します。

興味がある人のために、MvcContribでの使用に関するいくつかの背景情報...

これを個人的な好みとしてグリッドに追加しました-辞書としての匿名型の使用（ "オブジェクト"をとるパラメーターを持つことは、パラメーターFunc []をとるパラメーターと同じくらい不透明です）と、辞書コレクション初期化子がどちらかと言えば冗長です（私は冗長な流暢なインターフェイスのファンではありません。たとえば、Attribute（ "style"、 "display：none"）。Attribute（ "class"、 "foo"）などの複数の呼び出しをつなぎ合わせる必要があります）。

C＃の辞書リテラルの冗長構文が少なければ、グリッドコンポーネントにこの構文を含めても問題はありませんでした:)

また、MvcContribでのこれの使用は完全にオプションであることを指摘しておきます。これらは、代わりにIDictionaryを取るオーバーロードをラップする拡張メソッドです。このようなメソッドを提供する場合、他の言語との相互運用など、より「通常の」アプローチもサポートすることが重要だと思います。

また、誰かが「リフレクションオーバーヘッド」について言及し、このアプローチではオーバーヘッドが実際にはそれほどないことを指摘したいと思います。ランタイムリフレクションや式のコンパイルは含まれません（http://blog.bittercoder.comを参照）/PermaLink,guid,206e64d1-29ae-4362-874b-83f5b103727f.aspx）。

を好む

Attributes.Add(string name, string value);

これははるかに明示的で標準的であり、ラムダを使用しても何も得られません。

Rails Landへようこそ:)

何が起こっているのかを知っている限り、問題はありません。（問題があるのは、この種のことが十分に文書化されていないときです）。

Railsフレームワーク全体は、構成よりも規約の考え方に基づいて構築されています。特定の方法で物事に名前を付けると、それらが使用している規則に合わせて、無料で多くの機能を利用できます。命名規則に従うと、より速く進むことができます。すべてが見事に機能します。

このようなトリックを見た別の場所は、Moqのメソッド呼び出しアサーションです。ラムダを渡しますが、ラムダは実行されません。式を使用して、メソッド呼び出しが発生したことを確認し、発生しなかった場合は例外をスローします。

これは複数のレベルで恐ろしいことです。いいえ、これはRubyに似ていません。C＃と.NETの乱用です。

これをより簡単な方法で行う方法については、タプル、匿名型、流暢なインターフェースなど、多くの提案がありました。

何がそんなに悪いのかというと、それは自分の利益のために空想するための正しい方法です。

• これをVisual Basicから呼び出す必要がある場合はどうなりますか？

  .Attributes(Function(style) "width:100%")

• それは完全に直観に反するものであり、インテリセンスはものを渡す方法を理解するのにほとんど役立ちません。

• それは不必要に非効率的です。

• 誰もそれを維持する方法の手がかりはありません。

• 属性に入る引数のタイプは何ですか？それがありますかFunc<object,string>？その意図はどのように明らかになりますか？「オブジェクトのすべての値を無視してください」というIntellisenseのドキュメントにはどのような記述がありますか？

私はあなたがそれらの嫌悪感を持っていることを完全に正当化すると思います。

私は「構文の輝き」のキャンプにいます、彼らがそれを明確に文書化し、それがこのすごいクールに見えるなら、それはほとんど問題ありません！

それらの両方。それはラムダ式と構文の輝きの乱用です。

このような使い方をしたことはほとんどありません。「不適切」だと思います:)

これは一般的な使用方法ではなく、一般的な規則と一致していません。この種の構文には、もちろん長所と短所があります。

短所

• コードは直感的ではありません（通常の規則は異なります）
• 壊れやすい傾向があります（パラメーターの名前を変更すると機能が損なわれます）。
• テストは少し難しいです（APIを偽造するには、テストでリフレクションを使用する必要があります）。
• 式を集中的に使用すると、値（反射コスト）だけでなくパラメーターを分析する必要があるため、遅くなります

長所

• これは、開発者がこの構文に合わせた後の方が読みやすくなっています。

結論 -パブリックAPI設計では、より明示的な方法を選択したでしょう。

いいえ、それは確かに一般的な習慣ではありません。直感に反し、コードを見てそれが何をするのかを理解する方法はありません。それがどのように使用されるかを理解するには、それがどのように使用されるかを知る必要があります。

デリゲートの配列を使用して属性を提供する代わりに、メソッドのチェーンがより明確になり、パフォーマンスが向上します。

.Attribute("style", "width:100%;").Attribute("class", "test")

これはタイプするのが少し多いですが、それは明確で直感的です。

これを使用してフレーズを作成できますか？

magic lambda（n）：マジック文字列を置き換える目的でのみ使用されるラムダ関数。

次の何が問題になっています：

html.Attributes["style"] = "width:100%";

この「恐ろしさ」についてのすべての怒りは、長年のc＃の人の過剰反応です（そして私は長年のC＃プログラマーであり、言語の非常に大きなファンです）。この構文に恐ろしいことは何もありません。これは、構文を表現しようとしているものに似せようとする試みにすぎません。構文の「ノイズ」が少ないほど、プログラマはそれを理解しやすくなります。1行のコードでノイズを減らすことは少ししか役に立ちませんが、ますます多くのコードにまたがって蓄積していくと、かなりの利益になります。

これは、DSLが提供するのと同じ利点を追求するための作者による試みです。これが相互運用に適しているのか、それとも「複雑さ」のコストの一部を正当化するのに匿名メソッドよりも十分に優れているのかについて、議論することができます。十分に公正です...したがって、プロジェクトでは、この種の構文を使用するかどうかを適切に選択する必要があります。しかし、それでも...これはプログラマーが賢明な試みであり、結局のところ、私たちは皆、それを実現しようとしている（実現したかどうかにかかわらず）のです。そして、私たちがやろうとしているのはこれです。「コンピュータに何をしてほしいかを、コンピュータが何をしたいかについて考えている方法にできるだけ近い言語で伝えます。」

社内で考えるのと同じ方法でコンピューターへの指示を表現することに近づくことは、ソフトウェアをより保守可能かつ正確にするための鍵です。

編集：私は「ソフトウェアをより保守可能でより正確にするための鍵」と言っていました、それは狂ったように素朴で誇張されたユニコーン性のビットです。「鍵」に変更しました。

これは式ツリーの利点の1つです。追加情報についてコード自体を調べることができます。これは.Where(e => e.Name == "Jamie")、同等のSQL Where句に変換する方法です。これは表現ツリーの巧妙な使用法ですが、これ以上先に進まないようにしたいと思います。より複雑なものは、置き換えたいコードよりも難しくなる可能性が高いので、自己制限的ではないかと思います。

それは興味深いアプローチです。式の右辺を定数のみに制約した場合、次を使用して実装できます

Expression<Func<object, string>>

これは、デリゲートの代わりに本当に必要なものだと思います（ラムダを使用して両側の名前を取得しています）以下の単純な実装を参照してください。

public static IDictionary<string, string> Hash(params Expression<Func<object, string>>[] hash) {
    Dictionary<string, string> values = new Dictionary<string,string>();
    foreach (var func in hash) {
        values[func.Parameters[0].Name] = ((ConstantExpression)func.Body).Value.ToString();
    }
    return values;
}

これは、スレッドの前半で述べたクロス言語の相互運用性の懸念に対処することもできます。

コードは非常に賢いですが、潜在的にそれが解決するより多くの問題を引き起こします。

ご指摘のとおり、パラメーター名（スタイル）とHTML属性の間に不明瞭な依存関係が存在します。コンパイル時のチェックは行われません。パラメータ名が誤って入力された場合、ページにはおそらく実行時エラーメッセージは表示されませんが、ロジックバグを見つけるのははるかに困難です（エラーはありませんが、動作は正しくありません）。

より良い解決策は、コンパイル時にチェックできるデータメンバーを用意することです。これの代わりに：

.Attributes(style => "width:100%");

Styleプロパティを持つコードは、コンパイラーによってチェックできます。

.Attributes.Style = "width:100%";

あるいは：

.Attributes.Style.Width.Percent = 100;

これはコードの作成者にとってはより多くの作業ですが、このアプローチは、C＃の強力な型チェック機能を利用しており、最初からバグがコードに侵入するのを防ぎます。

実際、それはRuby =）のように見えます。少なくとも私にとって、後の動的な「ルックアップ」に静的リソースを使用することは、API設計の考慮事項に適合しません。このAPIでこの巧妙なトリックがオプションであることを願っています。

IDictionaryから継承するかどうかにかかわらず、値を設定するためにキーを追加する必要がない場合は、php配列のように動作するインデクサーを提供できます。これは、c＃だけでなく.netセマンティクスの有効な使用方法であり、ドキュメントも必要です。

お役に立てれば

私の意見では、それはラムダの乱用です。

構文の輝きに関しては、私はstyle=>"width:100%"明白に混乱します。特にの=>代わりに=

私見、それはそれを行うクールな方法です。クラスコントローラーに名前を付けると、MVCのコントローラーになるということは誰もが気に入っています。したがって、命名が重要な場合があります。

ここでの意図も非常に明確です。その.Attribute( book => "something")結果、book="something"そして結果的になることを理解することは非常に簡単.Attribute( log => "something")ですlog="something"

慣習のように扱っても問題ないと思います。私は、コードを少なくして意図を明らかにすることは何でも良いことだと思います。

メソッド（func）名が適切に選択されている場合、これはメンテナンスの頭痛を回避するための優れた方法です（つまり、新しいfuncを追加しますが、関数とパラメーターのマッピングリストに追加するのを忘れています）。もちろん、それを詳細に文書化する必要があり、そのクラスの関数のドキュメントからパラメーターのドキュメントを自動生成する方がよいでしょう...

これは「マジックストリング」に勝るとは思えません。私はこれについても、匿名タイプのファンではありません。それは、より良く強く型付けされたアプローチを必要とします。