.Net'teki lambda ifadelerinde kullanılan “=>” nasıl telaffuz edilir?

Çok nadiren başka programcılarla tanışıyorum!

Simgeyi ilk gördüğümde "ima ediyor" diye düşündüm, çünkü bunu matematiksel bir kanıtta olduğu gibi okuyacaktır, ama bu onun anlamı değildir.

Öyleyse nasıl olduğu gibi "=>" diyorum ya da okuyorum: -

IEnumerable<Person> Adults = people.Where(p => p.Age > 16)

Yoksa bunu kabul etmenin bir yolu var mı?

Bu operatörü okurken genellikle 'öyle ki' diyorum.

Örneğinizde, p => p.Age> 16, "P, yani p.Age 16'dan büyük olacak" şeklinde okunur.

Aslında, bu soruyu resmi linq yayın öncesi forumlarında sordum ve Anders Hejlsberg

Genellikle => operatörünü "olur" veya "hangisi" olarak okurum. Örneğin,
Func f = x => x * 2;
Func testi = c => cCity == "Londra";
"x x * 2 olur" ve "c.City Londra'ya eşittir" c olarak okunur

'Gittiği sürece' - bu benim için hiç mantıklı değil. 'p' hiçbir yere gitmiyor.

Birisine kod okuma durumunda, diyelim ki, telefon üzerinden, o zaman bir C # programcısı oldukları sürece, sadece 'lambda' kelimesini kullanırım - yani, "p lambda p nokta yaşı daha büyük on altı."

Steve Jessop, dönüşüm durumunda 'şuna eşleme' den bahsetti - bu yüzden Anders'i örnek alarak:

x => x * 2;

okuyacaktı

x, x çarpı 2 ile eşleşir.

Bu, kodun gerçek niyetine bu durum için 'olur'dan çok daha yakın görünüyor.

Gönderen MSDN :

Tüm lambda ifadeleri, "gider" olarak okunan lambda işlecini => kullanır.

Telefon Üzerinden Kod Okuma

Eric Lippert'den:

Ben şahsen c => c + 1 diyebilirim "görmek artı bir görmek gider". Duyduğum bazı varyasyonlar:

Bir projeksiyon için, (Müşteri c) => c.Adı: "müşteri görmek nokta adına bakın"

Bir tahmin için, (Müşteri c) => c.Age> 21: "müşteri, nokta yaşının yirmibirden fazla olduğunu görüyor"

Ben her zaman "wang operatörü" olarak adlandırdım :-)

"p wang yaşı p ​​16'dan büyük"

İnsanların "Ok" dediğini gördüm.

Ben bir LINQ kitabı bana söyledi çünkü "gider" kullanıyorum :)

"Haritalar" a ne dersiniz? Hem özlü hem de tartışmasız teknik olarak daha doğrudur (yani, "gider" veya "olur" ile olduğu gibi bir durum değişikliği önerisi yoktur, bir kümenin "böyle" veya "hangi" için olduğu gibi karakteristik işlevi ile bir birleşimi yoktur) diğer alternatifler. MSDN sayfasının ima ettiği gibi bir standart varsa, belki de sadece bununla gitmelisiniz (en azından C # kodu için).

"Haritalar", tercih ettiğim telaffuz. Matematiksel olarak konuşursak, bir fonksiyon argümanlarını dönüş değerine "eşler" (biri fonksiyona "haritalama" bile diyebilir), bu yüzden bu terminolojiyi programlamada, özellikle fonksiyonel programlama olarak kullanmak özellikle mantıklıdır (özellikle lambda hesabı) matematiğe çok yakın. Aynı zamanda bağlamdan da bahsedildiği gibi devlet değişikliğini önermediğinden, "olur", "gider" vb. Den daha tarafsızdır.

Çok fazla düşünmedim, ama sadece özlü bir şekilde "to" diyorum. Kısa ve özlü, ve değişken geçirilir ima etmek ifade. Sanırım 2 rakamı ("iki") ile karıştırılabilir, ama konuşurken "daha çok" ta "olarak telaffuz etme eğilimindeyim. Hiç kimse (en azından lambda'yı bilen) bana bunun belirsiz olduğunu düşündüklerini söylemedi ...

// "Func f equals x to x times two"
Func f = x=> x * 2;

// "Func test equals c to c dot City equals London"
Func test = c => c.City == "London"

Kısa cevabım: "c" lambda-of 'e ". Her ne kadar "'lambda' c 'fonksiyonu' e" ye yapışsam da, lambda-of ekümenik uzlaşmadır. Analiz takip eder.

Bu sadece garip cevaplar için harika bir soru. Tercümelerin çoğunun lambda ifadelerinden başka anlamları vardır, bu da egzotik yorumlara yol açar. Eski bir lambda-ifade korsanı olarak, sadece .NET notasyonunu görmezden gelir ve bunun için hemen hemen her şeyi yapmasını isterken kafamda lambda olarak yeniden yazarım.

Kodu telefon üzerinden anlatmak için birisinin kodu sırayla yazmasını istiyorsunuz. Tabii ki bu bir problem, ama lambda-ok ya da bir şey muhtemelen alabileceğiniz en iyisi ya da belki lambda-in, ama lambda-of en doğrudur.

Sorun, infix kullanımı ve her şeyi ve sol ve sağ kısımların rolünü, infix yerinde konuşulduğunda çalışan bir şeyle nasıl adlandırılacağıdır.

Bu aşırı kısıtlanmış bir sorun olabilir!

"Öyle ki" yi kullanmam. Çünkü bu, sağ tarafın, sol tarafın yerine getirmesi gereken bir yüklem olduğu anlamına geliyor. Bu, sol tarafın fonksiyonel bir parametre olarak soyutlandığı bir sağ taraf hakkında konuşmaktan çok farklıdır. ("Tüm lambda ifadeleri" hakkındaki MSDN bildirimi hem rahatsız edici hem de yanlıştır.)

Olabildiğince yakın olsa da "gider" hakkında bir şeyler sıralanır. "Gidiyor" bir dönüşümü ifade eder, ancak c'de bir ifadeye giden değişken c'nin tam olarak bir kısmı yoktur. Bir fonksiyonun soyutlanması biraz zor. Buna alışırdım, ama hala değişkenin soyutlanmasını vurgulayan bir şey arıyorum.

Sol taraf, şimdiye kadar kullanılan durumlarda her zaman basit bir tanımlayıcı olduğundan [ancak bunu daha sonra karıştırabilecek uzantıları bekleyin], "c => ifadesi" için "c 'lambda-işlev' ifadesini okuyacağımı düşünüyorum "" ve hatta "c" arg "işlevi" ifadesi ". Son durumda, "b 'arg' c 'arg' 'fonksiyon' ifadesi" gibi şeyler söyleyebilirim.

Bir lambda-ifadesinin tanıtıldığını ve "'arg' b 'arg' c 'işlevi' ifadesi" gibi bir şey söylediğini daha da netleştirmek daha iyi olabilir.

Tüm bunların diğer dillere nasıl çevrileceğini anlamak öğrenci için bir alıştırmadır [; <).

Hala "(b, c) => ifade" ve henüz yapmadılarsa ortaya çıkabilecek diğer varyantlar için endişeleniyorum. Belki de '' args 'b, c' fonksiyon 'ifadesi'.

Tüm bu düşüncelerden sonra, "c => e" yi "" lambda 'c' işlevi 'e "olarak çevirmeye geldiğimi ve tam biçime eşlemenin bağlamla anlaşılacağını fark ettim: λc (e ), c => e, f burada f (c) = e vb.

"Gidiyor" açıklamasının geçerli olacağını düşünüyorum çünkü baskın çoğunluk ilk kez lambda ifadelerini görecek. Ne yazık. İyi bir uzlaşma "c" lambda-of 'e "olabilir

Anonim yöntem olarak bir lambda ifadesi olduğunu düşünürseniz, "gider" yeterince iyi olur.

(n => n == String.Empty)

n, n == String.Empty ifadesine "gider".

Anonim yönteme gider, bu yüzden koddaki yönteme gitmek zorunda değilsiniz!

Bunun için özür dilerim.

Dürüst olmak gerekirse, kafamda "gider" kullanmak istemiyorum, ama diğer insanların garip göründüğünü söylediğini gördüm ve bunu açıklayacağımı düşündüm.

Önceki kapsamı elde etmenin dışında (bir lambda ifadesinin meydana geldiği noktada normal bir kod satırı için kapsamda olan tüm değişkenler ve sabitler, ifadenin koduna açıktır), bir lambda ifadesi, esasen bir satır içi fonksiyon için sözdizimsel şekerdir.

Üretim operatörünün solundaki değerlerin listesi ("=>"), bu işleve çağrı yapmak için kullanılan yığın çerçevesinin yapısına ve içeriğine katkıda bulunur. Değerler listesinin hem parametre bildirimlerine hem de iletilen bağımsız değişkenlere katkıda bulunduğunu söyleyebilirsiniz; daha geleneksel kodda, bunlar bir fonksiyona çağrı yapmak için kullanılan yığın çerçevesinin yapısını ve içeriğini belirler.

Sonuç olarak, değerler ifade koduna "gider". "İçin yığın çerçevesini tanımlar" veya "gider" demeyi tercih eder misiniz? :)

Filtre koşulları olarak kullanılan boole ifadelerinin dar olarak tanımlanmış uygulamasında (bu sorunun diğer cevapları tarafından kapsamlı bir şekilde dikkate alınan lambda ifadelerinin baskın kullanımı), kodun amacı lehine yöntemi atlamak çok mantıklıdır ve bu da " hangi "özlü olmak ve kodun anlamı hakkında daha fazla şey söylemek.

Bununla birlikte, lambda ifadeleri tek Linq eyaleti değildir ve bu bağlamın dışında daha genel olan "gider" biçimi kullanılmalıdır.

Ama neden "gider"?

Çünkü "aşağıdaki kodun yığın çerçevesini doldurur" bunu söyleyemeyecek kadar uzun. Sanırım "geçti / geçti" diyebilirsiniz.

Açıkça iletilen parametreler ve yakalanan değişkenler arasındaki önemli bir fark (doğru hatırlıyorsam - yanlışsam beni düzelt), birincisi referansla ve ikincisi değere göre geçirilir.

Sorunun bir kısmı, nasıl yapılandırıldığına bağlı olarak farklı şekilde yüksek sesle okuyabilmenizdir. Bu utanç gibi güzel ya da yakut |

Ruby'de, aynı sybmol'a "hashrocket" denir ve C # programcılarının da bu terimi kullandıklarını duydum (bunu yapmak yanlış olsa bile).

Benim görüşüm:

s => s.Age > 12 && s.Age < 20

"S parametresiyle Lambda İfadesi { return s.Age > 12 && s.Age < 20;}"

Bunu seviyorum çünkü bana lamdba ifadesinin nereden geldiğini hatırlatıyor

delegate(Student s) { return s.Age > 12 && s.Age < 20; };

=> sadece bir kısayoldur, bu nedenle delege anahtar sözcüğünü kullanmanız ve derleyici tarafından çıkarılabileceği için tür bilgisini eklemeniz gerekmez.

=> İçin terim gösterilen sonuçlara uygulandığı şekliyle

'result = s => s.Age > 12 && s.Age < 20'

s.Age 12 yaşından büyük ve s. 20 yaş altı

'result = x => x * 2'

x burada x 2 ile çarpılır

'result = c => c.City == "London"'

c.city, "Londra" ya eşittir

'result = n => n == String.Empty'

n burada n boş bir dizedir