Parametre adını yansıtan: C # lambda ifadelerinin kötüye kullanılması veya Sözdizimi parlaklığı?

MvcContrib Grid bileşenine bakıyorum ve Grid sözdiziminde kullanılan sözdizimsel bir hile ile hayran kaldım, ama aynı zamanda püskürttüm :

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

Yukarıdaki sözdizimi, oluşturulan HTML'nin stil niteliğini ayarlar width:100%. Şimdi dikkat ederseniz, 'stil' hiçbir yerde belirtilmez, ifadedeki parametrenin adından çıkarılır ! Bunu kazmak zorunda kaldım ve 'büyünün' nerede olduğunu buldum:

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

Aslında, kod öznitelik ad-değer çiftlerinin sözlüğünü oluşturmak için resmi, derleme zamanı, parametrelerin adını kullanıyor. Ortaya çıkan sözdizimi yapısı gerçekten çok etkileyici, ama aynı zamanda çok tehlikelidir. Lambda ifadelerinin genel kullanımı, yan etki olmadan kullanılan adların değiştirilmesine izin verir . Yazan bir kitapta bir örneğini görmek collection.ForEach(book => Fire.Burn(book))benim kodunda yazabilirim biliyorum collection.ForEach(log => Fire.Burn(log))ve aynı şeyi ifade . Ama burada MvcContrib Grid sözdizimi ile birdenbire, değişkenlerim için seçtiğim isimlere göre aktif olarak görünen ve kararlar veren kodu buluyorum!

Peki C # 3.5 / 4.0 topluluğu ve lambda ifadeleri sevenler ile bu ortak uygulama mı? Yoksa endişelenmemem gereken hileli bir hile mi?

Bu birlikte çalışmaz. Örneğin, bu C # - F # örneğini düşünün

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")

Sonuç:

"arg" yazdırılır ("yadda" değil).

Sonuç olarak, kütüphane tasarımcıları ya bu türden 'istismarlardan' kaçınmalı ya da .Net dillerinde iyi bir birlikte çalışmayı sağlamak istiyorlarsa, en azından bir 'standart' aşırı yük (örneğin, dize adını fazladan bir parametre olarak alır) sağlamalıdır.

Adı nedeniyle o kadar garip buluyorum , ama lambda gereksiz olduğu için ; anonim tür kullanabilir ve daha esnek olabilir:

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

Bu, ASP.NET MVC'nin çoğunda kullanılan bir modeldir (örneğin) ve başka kullanımları vardır (bir uyarı , adın arayana özgü değil sihirli bir değerse Ayende'nin düşüncelerine de dikkat edin )

Sadece benim fikrimi atmak istedim (ben MvcContrib ızgara bileşeninin yazarıyım).

Bu kesinlikle dil kötüye kullanımı - hiç şüphe yok. Ancak, gerçekten sezgisel karşı düşünmek olmaz - bir çağrı baktığınızda ne olduğunu Attributes(style => "width:100%", @class => "foo")
oldukça açık olduğunu düşünüyorum (Bu kesinlikle anonim türü yaklaşım daha kötü değil). Akıllı bir bakış açısıyla, oldukça opak olduğunu kabul ediyorum.

İlgilenenler için, MvcContrib'te kullanımı hakkında bazı arka plan bilgileri ...

Bunu kişisel bir tercih olarak ızgaraya ekledim - Anonim türlerin sözlük olarak kullanılmasını sevmiyorum ("nesne" alan bir parametreye sahip olmak, Func [] parametrelerini alan kadar opaktır) ve Dictionary collection başlatıcısı oldukça ayrıntılı (Ben de bir akıcı ("stil", "display: none") birden fazla çağrı birlikte zincirlemek zorunda, ayrıntılı akıcı arayüzlerin bir hayranı değilim. Attribute ("sınıf", "foo") vb)

C #, sözlük değişmez değerleri için daha az ayrıntılı bir sözdizimine sahip olsaydı, ızgara bileşenindeki bu sözdizimini dahil etmekten rahatsız olmazdım :)

Ayrıca bu MvcContrib içinde kullanımının tamamen isteğe bağlı olduğunu belirtmek istiyorum - bu yerine bir IDictionary almak aşırı yükleri sarma uzantı yöntemleri. Bunun gibi bir yöntem sağlarsanız, örneğin diğer dillerle birlikte çalışmak için daha 'normal' bir yaklaşımı desteklemeniz önemlidir.

Ayrıca, birisi 'yansıma yükünden' bahsetti ve sadece bu yaklaşımla çok fazla yükün olmadığını belirtmek istedim - çalışma zamanı yansıması veya ifade derlemesi yok (bkz. Http://blog.bittercoder.com /PermaLink,guid,206e64d1-29ae-4362-874b-83f5b103727f.aspx ).

tercih ederim

Attributes.Add(string name, string value);

Çok daha açık ve standart ve lambdalar kullanılarak hiçbir şey kazanılmıyor.

Rails Land'e Hoşgeldiniz :)

Neler olduğunu bildiğiniz sürece bununla ilgili yanlış bir şey yok. (Bu tür bir şeyin bir sorun olduğu iyi belgelenmediği zaman).

Rails çerçevesinin tamamı, yapılandırma üzerinde konvansiyon fikri üzerine inşa edilmiştir. İşleri belirli bir şekilde adlandırmak, kullandıkları bir sözleşmeye girmenizi sağlar ve ücretsiz olarak birçok işlevsellik elde edersiniz. Adlandırma kuralına uymak sizi daha hızlı gittiğiniz yere götürür. Her şey mükemmel çalışıyor.

Böyle bir hile gördüğüm başka bir yer, Moq'ta yöntem çağrısı iddialarında. Bir lambdadan geçersiniz, ancak lambda asla idam edilmez. İfadeyi sadece yöntem çağrısının gerçekleştiğinden emin olmak için kullanırlar ve eğer değilse bir istisna atarlar.

Bu korkunçBirden fazla seviyede . Ve hayır, bu Ruby gibi bir şey değil. Bu C # ve .Net kötüye kullanımı.

Bunun daha basit bir şekilde nasıl yapılacağına dair birçok öneri vardı: tuples, anonim tipler, akıcı bir arayüz vb.

Onu bu kadar kötü yapan şey, kendi iyiliği için süslemenin tek yoludur:

• Bunu VB'den çağırmanız gerektiğinde ne olur?

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

• Tamamen karşı sezgisel, akıllılığı, şeyleri nasıl aktaracağınızı anlamaya çok az yardım sağlayacaktır.

• Gereksiz yere verimsiz.

• Kimse onu nasıl koruyacağına dair bir ipucu olmayacak.

• Niteliklere giren argümanın türü nedir, değil Func<object,string>mi? Bu niyet nasıl ortaya çıkıyor. "Lütfen nesnenin tüm değerlerini dikkate almayın" diyeceğiniz akıllı dokümantasyonunuz nedir?

Bence bu tiksinti duygusuna sahip olmak tamamen haklısın.

Ben "sözdizimi parlak" kampındayım, eğer açıkça belgeliyorlarsa ve bu çılgınca havalı görünüyorsa, imo ile neredeyse hiç sorun yok!

Bunların her ikisi de. Bu lambda ifadelerinin ve sözdizimi parlaklığının kötüye kullanılmasıdır .

Bu tür bir kullanımla neredeyse hiç karşılaşmadım. Bence "uygunsuz" :)

Bu yaygın bir kullanım şekli değildir, genel sözleşmelerle tutarsızdır. Bu tür sözdiziminin elbette artıları ve eksileri vardır:

Eksileri

• Kod sezgisel değil (olağan sözleşmeler farklıdır)
• Kırılgan olma eğilimindedir (parametrenin yeniden adlandırılması işlevselliği bozacaktır).
• Test etmek biraz daha zor (API'yi taklit etmek testlerde yansıma kullanımını gerektirecektir).
• İfade yoğun bir şekilde kullanılırsa, sadece değeri değil, aynı zamanda parametreyi analiz etme ihtiyacı nedeniyle de daha yavaş olacaktır (yansıma maliyeti)

Artıları

• Geliştirici bu sözdizimine ayarlandıktan sonra daha okunabilir.

Alt satır - genel API tasarımında daha açık bir yol seçerdim.

Hayır, kesinlikle yaygın bir uygulama değil. Karşı-sezgisel, sadece ne yaptığını anlamak için koda bakmanın bir yolu yok. Nasıl kullanıldığını anlamak için nasıl kullanıldığını bilmelisiniz.

Bir dizi temsilci kullanarak öznitelik sağlamak yerine, zincirleme yöntemleri daha açık ve daha iyi performans gösterecektir:

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

Bu yazı yazmak için biraz daha fazla olsa da, açık ve sezgisel.

Bunu bir cümle yazmak için kullanabilir miyim?

magic lambda (n): yalnızca sihirli bir dizgiyi değiştirmek için kullanılan bir lambda işlevi.

Aşağıdakilerle ilgili sorun nedir:

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

"Korku" hakkında tüm bu ranting aşırı tepki uzun süre c # adamlar bir grup (ve ben uzun zamandır bir C # programcı ve hala dilin çok büyük bir hayranıyım). Bu sözdiziminde korkunç bir şey yok. Sadece sözdizimini daha çok ifade etmeye çalıştığınız gibi göstermeye çalışmaktır. Bir şeyin sözdiziminde ne kadar az "gürültü" varsa, programcı bunu o kadar kolay anlayabilir. Bir kod satırındaki gürültüyü azaltmak sadece biraz yardımcı olur, ancak daha fazla kodda birikmesine izin verin ve önemli bir fayda olduğu ortaya çıktı.

Bu, yazarın DSL'lerin sağladığı faydalar için çaba gösterme girişimidir - kod söylemeye çalıştığınız gibi "göründüğünde" büyülü bir yere ulaştınız. Bunun birlikte çalışma için iyi olup olmadığını veya "karmaşıklık" maliyetinin bir kısmını haklı çıkarmak için anonim yöntemlerden yeterli olup olmadığını tartışabilirsiniz. Yeterince adil ... yani projenizde bu tür sözdiziminin kullanılıp kullanılmayacağına dair doğru seçimi yapmalısınız. Ama yine de ... bu, bir programcı tarafından günün sonunda, hepimiz yapmaya çalıştığımız (bunu fark edip etmesek de) yapmaya çalışan akıllıca bir girişimdir. Ve hepimiz yapmaya çalıştığımız şey şudur: "Bilgisayara ne yapmasını istediğimizi mümkün olan en yakın dilde ne yapmasını istediğimizi anlatın."

Bilgisayarımıza talimatlarımızı dahili olarak düşündüğümüz şekilde ifade etmeye yaklaşmak, yazılımı daha sürdürülebilir ve daha doğru hale getirmenin anahtarıdır.

DÜZENLEME: "Yazılımı daha sürdürülebilir ve daha doğru hale getirmenin anahtarı" demiştim; "Anahtar" olarak değiştirdim.

Bu, ifade ağaçlarının faydalarından biridir - ekstra bilgi için kodun kendisini inceleyebilir. Bu .Where(e => e.Name == "Jamie")şekilde eşdeğer SQL Where yantümcesine dönüştürülebilir. Bu ifade ağaçlarının akıllıca kullanılmasıdır, ancak bundan daha ileri gitmeyeceğini umuyorum. Daha karmaşık bir şey, değiştirmeyi umduğu koddan daha zor olabilir, bu yüzden kendi kendini sınırlayacağından şüpheleniyorum.

Bu ilginç bir yaklaşım. İfadenin sağ tarafını yalnızca sabit olarak kısıtladıysanız şunu kullanarak uygulayabilirsiniz:

Expression<Func<object, string>>

Hangi delege yerine gerçekten istediğinizi düşünüyorum (her iki tarafın adlarını almak için lambda kullanıyorsunuz) Aşağıdaki naif uygulamaya bakın:

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;
}

Bu, daha önce iş parçacığında bahsedilen çapraz dil birlikte çalışma endişesini de giderebilir.

Kod çok zekidir, ancak potansiyel olarak çözdüğü daha fazla soruna neden olur.

İşaret ettiğiniz gibi, şimdi parametre adı (stil) ve bir HTML özelliği arasında belirsiz bir bağımlılık var. Derleme zamanı kontrolü yapılmaz. Parametre adı yanlış yazılırsa, sayfada muhtemelen bir çalışma zamanı hata mesajı olmaz, ancak mantık hatası bulmak çok daha zordur (hata yok, ancak yanlış davranış).

Daha iyi bir çözüm, derleme zamanında kontrol edilebilen bir veri elemanına sahip olmak olacaktır. Bunun yerine:

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

bir Style özelliğine sahip kod derleyici tarafından kontrol edilebilir:

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

ya da:

.Attributes.Style.Width.Percent = 100;

Bu, kod yazarları için daha fazla iştir, ancak bu yaklaşım, C # 'ın güçlü tür kontrol yeteneğinden yararlanır, bu da hataların ilk etapta kodlara girmesini önlemeye yardımcı olur.

gerçekten Ruby =) gibi görünüyor, en azından benim için daha sonra dinamik bir "arama" için statik bir kaynak kullanımı api tasarım dikkate uymuyor, umarım bu akıllı hile bu api isteğe bağlıdır.

IDictionary (veya değil) devralmak ve bir değer ayarlamak için bir anahtar eklemeniz gerekmediğinde bir php dizi gibi davranan bir dizinleyici sağlayabilir. Bu, yalnızca c # değil, .net semantiğinin geçerli bir kullanımı olacaktır ve yine de belgelere ihtiyaç duyar.

Bu yardımcı olur umarım

Bence bu lambdaların kötüye kullanılması.

Sözdizimi parlaklığı için style=>"width:100%"düz kafa karıştırıcı buluyorum . Özellikle =>yerine=

IMHO, bunu yapmanın harika bir yolu. Hepimiz bir sınıf Kontrolörü adlandırmanın MVC'de bir kontrolör yapmasını seviyoruz değil mi? Yani isimlendirmenin önemli olduğu durumlar var.

Ayrıca burada niyet çok açık. O anlamak çok kolaydır .Attribute( book => "something")sonuçlanacaktır book="something"ve.Attribute( log => "something") sonuçlanacaktırlog="something"

Bir kongre gibi davranırsanız bir sorun olmamalı sanırım. Ben daha az kod yazmak ve niyeti açık kılan ne olursa olsun iyi bir şey olduğunu düşünüyorum.

Yöntem (func) adları iyi seçilmişse, bu bakım baş ağrısından kaçınmanın mükemmel bir yoludur (yani: yeni bir işlev ekleyin, ancak işlev-parametre eşleme listesine eklemeyi unutun). Tabii ki, bunu ağır bir şekilde belgelemeniz gerekiyor ve bu sınıftaki işlevler için belgelerden parametreler için belgeleri otomatik olarak oluşturmanız daha iyi olur ...

Bence bu "sihirli iplerden" daha iyi değil. Ben de bunun için anonim türlerin hayranı değilim. Daha iyi ve güçlü bir şekilde yazılmış bir yaklaşıma ihtiyaç duyar.