Scala görevlendirmesinin atanan değerden ziyade Birim'e göre değerlendirilmesinin motivasyonu nedir?

Scala görevlendirmesinin atanan değerden ziyade Birim'e göre değerlendirilmesinin motivasyonu nedir?

G / Ç programlamasında yaygın bir model, aşağıdaki gibi şeyler yapmaktır:

while ((bytesRead = in.read(buffer)) != -1) { ...

Ancak Scala'da bu mümkün değil çünkü ...

bytesRead = in.read(buffer)

.. bytesRead'in yeni değerini değil, Birim'i döndürür.

İşlevsel bir dilin dışında bırakmak ilginç bir şey gibi görünüyor. Neden böyle yapıldığını merak ediyorum?

Atamaların birim yerine atanan değeri döndürmesini savundum. Martin ve ben bunun üzerinde ileri geri gittik, ancak onun argümanı, yığına zamanın% 95'ini çıkarmak için bir değer koymanın bayt kodlarının boşa harcanması ve performans üzerinde olumsuz bir etkiye sahip olduğuydu.

Gerçek nedenler hakkında içeriden bilgi alamıyorum, ancak şüphem çok basit. Scala, programcıların doğal olarak anlamak için tercih etmeleri için yan etkili döngülerin kullanımını garip hale getirir.

Bunu birçok şekilde yapar. Örneğin, forbir değişkeni bildirdiğiniz ve değiştirdiğiniz bir döngünüz yok. Bir whiledöngüdeki durumu (kolayca) mutasyona uğratamazsınız , aynı zamanda koşulu test edersiniz, bu da mutasyonu genellikle ondan hemen önce ve sonunda tekrarlamanız gerektiği anlamına gelir. Bir whileblok içinde bildirilen değişkenler whiletest koşulundan görünmez , bu da do { ... } while (...)daha az kullanışlı hale getirir . Ve bunun gibi.

Çözüm:

while ({bytesRead = in.read(buffer); bytesRead != -1}) { ... 

Değeri ne olursa olsun.

Alternatif bir açıklama olarak, belki Martin Odersky, bu tür kullanımdan kaynaklanan çok çirkin birkaç hatayla yüzleşmek zorunda kaldı ve bunu kendi dilinden yasaklamaya karar verdi.

DÜZENLE

David Pollack , yanıtını Martin Odersky'nin kendisinin de Pollack tarafından ortaya konan performansla ilgili konular argümanına güvenerek yorumladığı gerçeğiyle açıkça onaylanan bazı gerçek gerçeklerle yanıtladı .

Bu, Scala'nın daha "resmi olarak doğru" bir tip sistemine sahip olmasının bir parçası olarak gerçekleşti. Resmi olarak konuşursak, atama tamamen yan etkiye sahip bir ifadedir ve bu nedenle geri dönmelidir Unit. Bunun bazı güzel sonuçları var; Örneğin:

class MyBean {
  private var internalState: String = _

  def state = internalState

  def state_=(state: String) = internalState = state
}

state_=Yöntemi döndürür Unit(bir ayarlayıcı için beklenen) tam atama döner, çünkü Unit.

Bir akışı veya benzerini kopyalamak gibi C tarzı desenler için bu özel tasarım kararının biraz zahmetli olabileceğine katılıyorum. Ancak, aslında genel olarak nispeten problemsizdir ve tip sisteminin genel tutarlılığına gerçekten katkıda bulunur.

Belki de bu komut-sorgu ayırma ilkesinden kaynaklanmaktadır?

CQS, yan etkileri olan veya olmayan (yani nesneyi değiştiren) nesne yöntemleri arasında bariz bir ayrım yarattığı için OO ve fonksiyonel programlama stillerinin kesişme noktasında popüler olma eğilimindedir. CQS'yi değişken atamalara uygulamak, her zamankinden daha ileri götürür, ancak aynı fikir geçerlidir.

CQS yararlıdır neden kısa bir gösterimidir: bir hipotetik hibrid F / OO dili göz önünde Listyöntemleri vardır sınıfı Sort, Append, Firstve Length. Zorunlu OO tarzında, şöyle bir işlev yazmak isteyebilir:

func foo(x):
    var list = new List(4, -2, 3, 1)
    list.Append(x)
    list.Sort()
    # list now holds a sorted, five-element list
    var smallest = list.First()
    return smallest + list.Length()

Daha işlevsel bir tarzda ise, şunun gibi bir şey yazılması daha olasıdır:

func bar(x):
    var list = new List(4, -2, 3, 1)
    var smallest = list.Append(x).Sort().First()
    # list still holds an unsorted, four-element list
    return smallest + list.Length()

Bunlar aynı şeyi yapmaya çalışıyor gibi görünüyor , ancak ikisinden biri yanlış ve yöntemlerin davranışları hakkında daha fazla bilgi sahibi olmadan hangisi olduğunu bilemiyoruz.

Bununla birlikte, CQS'yi kullanarak , listeyi değiştirir Appendve Sortdeğiştirirlerse, birim türünü döndürmeleri gerektiği konusunda ısrarcı oluruz , böylece yapmamamız gerektiğinde ikinci formu kullanarak hatalar oluşturmamızı engelleriz. Yan etkilerin varlığı bu nedenle yöntem imzasında da örtük hale gelir.

Sanırım bu, programı / dili yan etkilerden uzak tutmak için.

Tanımladığınız şey, genel durumda kötü bir şey olarak kabul edilen bir yan etkinin kasıtlı olarak kullanılmasıdır.

Bir atamayı boole ifadesi olarak kullanmak en iyi stil değildir. Aynı anda iki şeyi gerçekleştirirsiniz, bu da sıklıkla hatalara yol açar. Ve Scalas kısıtlamasıyla "==" yerine "=" nin yanlışlıkla kullanılması önlenir.

Bu arada: Başlangıçtaki while-trick'i Java'da bile aptalca buluyorum. Neden böyle bir şey olmasın?

for(int bytesRead = in.read(buffer); bytesRead != -1; bytesRead = in.read(buffer)) {
   //do something 
}

Verilmiş, ödev iki kez görünüyor, ancak en azından bytesRead ait olduğu kapsamda ve komik atama hileleriyle oynamıyorum ...

Yönlendirme için bir referans türünüz olduğu sürece bunun için bir geçici çözüm bulabilirsiniz. Deneyimsiz bir uygulamada, rastgele türler için aşağıdakileri kullanabilirsiniz.

case class Ref[T](var value: T) {
  def := (newval: => T)(pred: T => Boolean): Boolean = {
    this.value = newval
    pred(this.value)
  }
}

Ardından, ref.valuedaha sonra referansa erişmek için kullanmanız gereken kısıtlama altında, whileyükleminizi şu şekilde yazabilirsiniz:

val bytesRead = Ref(0) // maybe there is a way to get rid of this line

while ((bytesRead := in.read(buffer)) (_ != -1)) { // ...
  println(bytesRead.value)
}

ve karşı denetimi yazmak bytesReadzorunda kalmadan daha örtük bir şekilde yapabilirsiniz.