การสะท้อนชื่อพารามิเตอร์: การใช้ C # lambda หรือการใช้ไวยากรณ์ที่ไม่เหมาะสม?

ฉันกำลังดูส่วนประกอบของMvcContrib Grid และฉันก็รู้สึกทึ่ง แต่ในเวลาเดียวกันกลับกลายเป็นว่าเป็นกลอุบายที่ใช้ในไวยากรณ์ไวยากรณ์ :

.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 Grid ที่นี่ทั้งหมดในทันทีฉันพบรหัสที่มีลักษณะและการตัดสินใจตามชื่อที่ฉันเลือกสำหรับตัวแปรของฉัน!

ดังนั้นนี่คือการปฏิบัติร่วมกันกับชุมชน C # 3.5 / 4.0 และคนรักการแสดงออกแลมบ์ดา? หรือเป็นคนหลอกลวงที่หลอกลวงคนหนึ่งที่ฉันไม่ควรกังวลอะไร?

สิ่งนี้มีการทำงานร่วมกันที่ไม่ดี ตัวอย่างเช่นลองพิจารณาตัวอย่าง C # - F # นี้

ค#:

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")
ฉันคิดว่ามันค่อนข้างชัดเจนว่าเกิดอะไรขึ้น จากมุมมองของ Intellisense ฉันเห็นว่ามันค่อนข้างทึบ

สำหรับผู้ที่สนใจข้อมูลพื้นฐานบางอย่างเกี่ยวกับการใช้งานใน MvcContrib ...

ฉันเพิ่มสิ่งนี้ลงในกริดตามความชอบส่วนตัว - ฉันไม่ชอบการใช้งานประเภทที่ไม่ระบุตัวตนเป็นพจนานุกรม (มีพารามิเตอร์ที่ใช้ "วัตถุ" เป็นทึบแสงเช่นเดียวกับที่ใช้ params Func []) และ initializer คอลเลกชันพจนานุกรมคือ ค่อนข้าง verbose (ฉันไม่ได้เป็นแฟนของอินเตอร์เฟซคล่องแคล่ว verbose เช่นมีสายเข้าด้วยกันหลายสายไปยังแอตทริบิวต์ ("สไตล์", "display: none") แอตทริบิวต์ ("class", "foo") ฯลฯ )

ถ้า C # มีไวยากรณ์ verbose น้อยกว่าสำหรับตัวอักษรพจนานุกรมดังนั้นฉันจะไม่ต้องใส่ใจรวมถึงไวยากรณ์นี้ในองค์ประกอบกริด :)

ฉันยังต้องการชี้ให้เห็นว่าการใช้งาน MVCContrib นี้เป็นทางเลือกอย่างสมบูรณ์ - นี่เป็นวิธีการขยายที่ตัดการโอเวอร์โหลดที่ใช้ IDictionary แทน ฉันคิดว่ามันเป็นสิ่งสำคัญที่หากคุณให้วิธีการเช่นนี้คุณควรสนับสนุนวิธีการที่ 'ปกติ' มากขึ้นเช่นสำหรับการใช้ภาษาอื่น ๆ

นอกจากนี้มีคนพูดถึง 'ภาพสะท้อนค่าโสหุ้ย' และฉันแค่ต้องการชี้ให้เห็นว่าวิธีการนี้มีค่าใช้จ่ายไม่มาก - ไม่มีการสะท้อนแบบไทม์หรือการรวบรวมการแสดงออกที่เกี่ยวข้อง (ดูhttp://blog.bittercoder.com /PermaLink,guid,206e64d1-29ae-4362-874b-83f5b103727f.aspx )

ฉันต้องการ

Attributes.Add(string name, string value);

มันชัดเจนและเป็นมาตรฐานมากกว่าและไม่มีอะไรได้มาจากการใช้ lambdas

ยินดีต้อนรับสู่ Rails Land :)

มันไม่มีอะไรผิดปกติกับมันตราบใดที่คุณรู้ว่าเกิดอะไรขึ้น (เมื่อชนิดของสิ่งนี้ไม่ได้บันทึกไว้อย่างดีว่ามีปัญหา)

เฟรมเวิร์กทั้งหมดของ Rails สร้างขึ้นจากแนวคิดของการประชุมเรื่องการตั้งค่า การตั้งชื่อบางอย่างเป็นสิ่งสำคัญที่จะนำคุณไปสู่การประชุมที่พวกเขากำลังใช้และคุณจะได้รับฟังก์ชั่นมากมายฟรี การทำตามแบบแผนการตั้งชื่อทำให้คุณไปได้เร็วขึ้น สิ่งทั้งหมดทำงานได้อย่างยอดเยี่ยม

อีกสถานที่ที่ฉันได้เห็นกลอุบายเช่นนี้อยู่ในการยืนยันวิธีการโทรใน Moq คุณผ่านแลมบ์ดา แต่แลมบ์ดาไม่เคยถูกประหารชีวิต พวกเขาเพียงใช้นิพจน์เพื่อให้แน่ใจว่ามีการเรียกเมธอดและโยนข้อยกเว้นถ้าไม่

มันน่ากลัวในระดับมากกว่าหนึ่ง และไม่นี่คือไม่มีอะไรเหมือนทับทิม มันเป็นการละเมิด C # และ. Net

มีข้อเสนอแนะมากมายเกี่ยวกับวิธีการทำสิ่งนี้ในลักษณะตรงไปตรงมามากขึ้น: tuples ประเภทที่ไม่ระบุชื่ออินเทอร์เฟซที่คล่องแคล่วและอื่น ๆ

สิ่งที่ทำให้มันเลวร้ายคือวิธีการที่จะจินตนาการถึงความดีของตัวเอง:

• เกิดอะไรขึ้นเมื่อคุณต้องการเรียกสิ่งนี้จาก VB?

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

• ระบบ Intellisense ตอบโต้ได้อย่างสมบูรณ์แบบจะให้ความช่วยเหลือเล็กน้อยในการหาวิธีการส่งผ่านข้อมูล

• มันไม่มีประสิทธิภาพโดยไม่จำเป็น

• ไม่มีใครรู้ว่าจะดูแลมันได้อย่างไร

• อะไรคือประเภทของการโต้แย้งไปสู่คุณลักษณะมันคือFunc<object,string>อะไร? ความตั้งใจนั้นเปิดเผยอย่างไร เอกสาร Intellisense ของคุณคืออะไรที่จะพูดว่า "โปรดเพิกเฉยต่อค่าทั้งหมดของวัตถุ"

ฉันคิดว่าคุณเป็นคนชอบธรรมที่มีความรู้สึกรังเกียจอย่างสมบูรณ์

ฉันอยู่ในค่าย "syntax brilliance" ถ้าพวกมันบันทึกไว้อย่างชัดเจนและมันดูเท่มาก ๆ มันก็แทบจะไม่มีปัญหาอะไรกับมันเลย!

เขาทั้งคู่. มันเป็นการลบล้างการแสดงออกแลมบ์ดาและความหมายของไวยากรณ์

ฉันแทบจะไม่เคยเจอการใช้งานประเภทนี้ ฉันคิดว่ามัน "ไม่เหมาะสม" :)

นี่ไม่ใช่วิธีการใช้งานทั่วไปมันไม่สอดคล้องกับอนุสัญญาทั่วไป ไวยากรณ์ชนิดนี้มีข้อดีข้อเสียแน่นอน:

จุดด้อย

• รหัสไม่ง่าย (การประชุมทั่วไปแตกต่างกัน)
• มันมีแนวโน้มที่จะเปราะบาง (การเปลี่ยนชื่อพารามิเตอร์จะทำลายการทำงาน)
• เป็นการทดสอบที่ยากขึ้นเล็กน้อย (การแกล้งทำ API จะต้องใช้การสะท้อนกลับในการทดสอบ)
• หากใช้นิพจน์อย่างเข้มข้นจะช้าลงเนื่องจากต้องวิเคราะห์พารามิเตอร์ไม่ใช่เฉพาะค่า (ค่าสะท้อน)

ข้อดี

• สามารถอ่านได้มากขึ้นหลังจากผู้พัฒนาปรับเป็นไวยากรณ์นี้

บรรทัดล่าง - ในการออกแบบ API สาธารณะฉันจะเลือกวิธีที่ชัดเจนกว่านี้

ไม่แน่นอนไม่ใช่เรื่องธรรมดา มันตอบโต้ง่ายไม่มีทางที่จะดูรหัสเพื่อดูว่ามันทำอะไร คุณต้องรู้ว่ามันคุ้นเคยกับวิธีการใช้งานของมันอย่างไร

แทนที่จะจัดหาแอตทริบิวต์โดยใช้อาร์เรย์ของผู้รับมอบสิทธิ์วิธีการผูกมัดจะชัดเจนและทำงานได้ดีขึ้น:

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

แม้ว่านี่จะเป็นแบบอื่น ๆ อีกเล็กน้อย แต่ก็ชัดเจนและใช้งานง่าย

ฉันสามารถใช้สิ่งนี้เพื่อเหรียญวลี?

magic lambda (n): ฟังก์ชั่นแลมบ์ดาใช้เพื่อจุดประสงค์ในการเปลี่ยนสายเวทเท่านั้น

มีอะไรผิดปกติกับสิ่งต่อไปนี้:

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

ทั้งหมดนี้คุยโวเกี่ยวกับ "ความน่ากลัว" เป็นพวงของ c # guys นานเกินจริง (และฉันเป็นโปรแกรมเมอร์ C # เป็นเวลานานและยังคงเป็นแฟนตัวยงของภาษา) ไม่มีอะไรน่ากลัวเกี่ยวกับไวยากรณ์นี้ มันเป็นเพียงความพยายามในการทำให้ไวยากรณ์ดูเหมือนสิ่งที่คุณพยายามแสดง "เสียง" ที่น้อยลงมีอยู่ในไวยากรณ์สำหรับบางสิ่งบางอย่างง่ายขึ้นโปรแกรมเมอร์สามารถเข้าใจได้ การลดเสียงรบกวนในรหัสบรรทัดเดียวจะช่วยได้เพียงเล็กน้อยเท่านั้น แต่ปล่อยให้สิ่งนั้นสร้างขึ้นในรหัสที่มากขึ้นเรื่อย ๆ และกลายเป็นประโยชน์อย่างมาก

นี่เป็นความพยายามของผู้เขียนที่จะพยายามให้ได้รับประโยชน์เช่นเดียวกับที่ DSL มอบให้คุณเมื่อโค้ดดูเหมือน "สิ่งที่คุณพยายามจะพูดคุณก็มาถึงสถานที่มหัศจรรย์ คุณสามารถถกเถียงว่าสิ่งนี้เป็นสิ่งที่ดีสำหรับการทำงานร่วมกันหรือว่าดีกว่าวิธีที่ไม่ระบุชื่อเพื่อประเมินต้นทุน "ความซับซ้อน" ยุติธรรมพอ ... ดังนั้นในโครงการของคุณคุณควรเลือกว่าจะใช้ไวยากรณ์ประเภทนี้หรือไม่ แต่ถึงกระนั้น ... นี่เป็นความพยายามอันชาญฉลาดของโปรแกรมเมอร์ที่จะทำอะไรในตอนท้ายของวันเราทุกคนพยายามทำ (ไม่ว่าเราจะรู้หรือไม่ก็ตาม) และสิ่งที่เราทุกคนพยายามทำคือ: "บอกคอมพิวเตอร์ว่าเราต้องการให้มันทำอะไรในภาษาที่ใกล้เคียงที่สุดกับวิธีที่เราคิดเกี่ยวกับสิ่งที่ต้องการให้ทำ"

ใกล้ชิดกับการแสดงคำแนะนำของเราไปยังคอมพิวเตอร์ในลักษณะเดียวกันกับที่เราคิดว่าภายในเป็นกุญแจสำคัญในการทำให้ซอฟต์แวร์บำรุงรักษาได้มากขึ้นและแม่นยำยิ่งขึ้น

แก้ไข: ฉันได้กล่าวว่า "กุญแจสำคัญในการทำให้ซอฟต์แวร์บำรุงรักษาได้มากขึ้นและแม่นยำยิ่งขึ้น" ซึ่งเป็นบิตที่ไร้เดียงสาอย่างไร้เดียงสาที่พูดเกินจริง ฉันเปลี่ยนเป็น "กุญแจ"

นี่คือหนึ่งในประโยชน์ของต้นไม้นิพจน์ - หนึ่งสามารถตรวจสอบรหัสของตัวเองสำหรับข้อมูลเพิ่มเติม นั่นคือวิธีที่.Where(e => e.Name == "Jamie")สามารถแปลงเป็น SQL เทียบเท่าได้ที่ไหน นี่เป็นการใช้ต้นไม้แสดงออกอย่างชาญฉลาด แต่ฉันหวังว่ามันจะไม่ไปไกลกว่านี้อีก สิ่งที่ซับซ้อนกว่านั้นมีแนวโน้มว่าจะยากกว่าโค้ดที่หวังจะเปลี่ยนดังนั้นฉันสงสัยว่ามันจะเป็นการ จำกัด ตัวเอง

มันเป็นวิธีการที่น่าสนใจ หากคุณ จำกัด ทางด้านขวาของนิพจน์ให้เป็นค่าคงที่เท่านั้นคุณสามารถนำไปใช้งานได้

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 เมื่อคุณไม่ต้องการเพิ่มคีย์เพื่อตั้งค่า มันจะเป็นการใช้งานที่ถูกต้องของ. net semantics ไม่ใช่แค่ c # และยังต้องการเอกสารประกอบ

หวังว่านี่จะช่วยได้

ในความคิดของฉันมันเป็นการละเมิดของ lambdas

ในฐานะที่เป็นความสามารถด้านไวยากรณ์ฉันพบstyle=>"width:100%"ความสับสนธรรมดา โดยเฉพาะอย่างยิ่งเพราะ=>แทนที่จะเป็น=

IMHO มันเป็นวิธีที่ยอดเยี่ยมในการทำ เราทุกคนชอบความจริงที่ว่าการตั้งชื่อตัวควบคุมคลาสจะทำให้มันเป็นตัวควบคุมใน MVC ใช่มั้ย ดังนั้นจึงมีหลายกรณีที่การตั้งชื่อไม่สำคัญ

นอกจากนี้ความตั้งใจชัดเจนมากที่นี่ มันง่ายมากที่จะเข้าใจว่า.Attribute( book => "something")จะส่งผลbook="something"และ.Attribute( log => "something")จะส่งผลให้log="something"

ฉันคิดว่ามันไม่น่าจะมีปัญหาถ้าคุณปฏิบัติต่อมันเหมือนการประชุม ฉันเห็นว่าอะไรก็ตามที่ทำให้คุณเขียนโค้ดน้อยลงและทำให้ความตั้งใจชัดเจนเป็นสิ่งที่ดี

หากชื่อเมธอด (func) ได้รับการคัดเลือกเป็นอย่างดีนี่เป็นวิธีที่ยอดเยี่ยมในการหลีกเลี่ยงการปวดหัวการบำรุงรักษา (เช่น: เพิ่ม func ใหม่ แต่ลืมที่จะเพิ่มลงในรายการการแมปฟังก์ชันพารามิเตอร์พารามิเตอร์) แน่นอนคุณต้องจัดทำเอกสารอย่างหนักและคุณควรสร้างเอกสารสำหรับพารามิเตอร์จากเอกสารสำหรับฟังก์ชั่นในคลาสนั้นโดยอัตโนมัติ

ฉันคิดว่านี่ไม่ดีไปกว่า "สายเวท" ฉันไม่ได้เป็นแฟนของประเภทที่ไม่ระบุชื่อเช่นกัน มันต้องการแนวทางที่ดีกว่าและพิมพ์ออกมาอย่างแรง