Động lực để Scala phân công đánh giá cho Đơn vị hơn là giá trị được giao là gì?

Động lực để Scala phân công đánh giá cho Đơn vị hơn là giá trị được giao là gì?

Mô hình phổ biến trong lập trình I / O là làm những việc như sau:

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

Nhưng điều này là không thể trong Scala vì ...

bytesRead = in.read(buffer)

.. trả về Đơn vị, không phải giá trị mới của byteRead.

Có vẻ như một điều thú vị khi bỏ qua một ngôn ngữ chức năng. Tôi đang tự hỏi tại sao nó được thực hiện như vậy?

Tôi ủng hộ việc có các nhiệm vụ trả lại giá trị được chỉ định thay vì đơn vị. Martin và tôi đã quay đi quay lại về nó, nhưng lập luận của anh ấy là việc đặt một giá trị trên ngăn xếp chỉ để bật ra 95% thời gian là một sự lãng phí mã byte và có tác động tiêu cực đến hiệu suất.

Tôi không rành về thông tin nội bộ về lý do thực tế, nhưng sự nghi ngờ của tôi rất đơn giản. Scala làm cho các vòng lặp có tác dụng phụ trở nên khó sử dụng để các lập trình viên tự nhiên thích hiểu hơn.

Nó thực hiện điều này theo nhiều cách. Ví dụ: bạn không có forvòng lặp nơi bạn khai báo và thay đổi một biến. Bạn không thể (dễ dàng) đột biến trạng thái trên một whilevòng lặp cùng lúc bạn kiểm tra điều kiện, có nghĩa là bạn thường phải lặp lại đột biến ngay trước nó và ở cuối nó. Các biến được khai báo bên trong một whilekhối không thể nhìn thấy được từ whileđiều kiện thử nghiệm, điều này làm cho do { ... } while (...)ít hữu ích hơn nhiều. Và như thế.

Cách giải quyết:

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

Đối với bất cứ điều gì nó là giá trị.

Như một lời giải thích khác, có lẽ Martin Odersky đã phải đối mặt với một vài lỗi rất xấu do việc sử dụng như vậy, và quyết định cấm nó khỏi ngôn ngữ của mình.

BIÊN TẬP

David Pollack đã trả lời bằng một số dữ kiện thực tế, được xác nhận rõ ràng bởi thực tế là chính Martin Odersky đã bình luận câu trả lời của mình, chứng tỏ sự tin cậy đối với lập luận về các vấn đề liên quan đến hiệu suất do Pollack đưa ra.

Điều này xảy ra như một phần của việc Scala có một hệ thống kiểu "chính thức" hơn. Nói một cách chính thức, nhiệm vụ là một tuyên bố hoàn toàn có tác dụng phụ và do đó nên quay trở lại Unit. Điều này có một số hậu quả tốt đẹp; ví dụ:

class MyBean {
  private var internalState: String = _

  def state = internalState

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

Các state_=trở về phương pháp Unit(như sẽ được dự kiến cho một setter) chính vì lợi nhuận chuyển nhượng Unit.

Tôi đồng ý rằng đối với các mẫu kiểu C như sao chép luồng hoặc tương tự, quyết định thiết kế cụ thể này có thể hơi rắc rối. Tuy nhiên, nó thực sự tương đối không có vấn đề nói chung và thực sự đóng góp vào tính nhất quán tổng thể của hệ thống kiểu.

Có lẽ điều này là do nguyên tắc tách lệnh-truy vấn ?

CQS có xu hướng phổ biến ở giao điểm của kiểu lập trình OO và chức năng, vì nó tạo ra sự khác biệt rõ ràng giữa các phương thức đối tượng có hoặc không có tác dụng phụ (tức là làm thay đổi đối tượng). Việc áp dụng CQS cho các nhiệm vụ thay đổi đang đưa nó đi xa hơn bình thường, nhưng ý tưởng tương tự cũng được áp dụng.

Một minh họa ngắn về việc tại sao CQS rất hữu ích: Xem xét một giả thuyết lai ngôn ngữ F / OO với một Listlớp mà có phương pháp Sort, Append, First, và Length. Trong kiểu OO bắt buộc, người ta có thể muốn viết một hàm như sau:

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

Trong khi theo phong cách chức năng hơn, nhiều khả năng người ta sẽ viết một cái gì đó như thế này:

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

Những điều này dường như đang cố gắng làm điều tương tự, nhưng rõ ràng một trong hai phương thức là không chính xác, và nếu không biết thêm về hoạt động của các phương thức, chúng ta không thể biết phương thức nào.

Tuy nhiên, sử dụng CQS, chúng tôi sẽ nhấn mạnh rằng nếu Appendvà Sortthay đổi danh sách, chúng phải trả về loại đơn vị, do đó ngăn chúng tôi tạo lỗi bằng cách sử dụng biểu mẫu thứ hai khi chúng tôi không nên. Do đó, sự hiện diện của các tác dụng phụ cũng trở nên tiềm ẩn trong chữ ký của phương pháp.

Tôi đoán điều này là để giữ cho chương trình / ngôn ngữ không có tác dụng phụ.

Những gì bạn mô tả là việc cố ý sử dụng một tác dụng phụ mà trong trường hợp chung được coi là một điều xấu.

Đây không phải là kiểu tốt nhất để sử dụng một phép gán dưới dạng biểu thức boolean. Bạn thực hiện hai việc cùng một lúc nên thường dẫn đến sai sót. Và việc vô tình sử dụng "=" thay vì "==" được tránh với giới hạn Scalas.

Nhân tiện: Tôi thấy thủ thuật while ban đầu thật ngu ngốc, ngay cả trong Java. Tại sao không phải là somethign như thế này?

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

Đúng là, bài tập xuất hiện hai lần, nhưng ít nhất byteRead nằm trong phạm vi nó thuộc về và tôi không chơi với các thủ thuật chuyển nhượng vui nhộn ...

Bạn có thể có một giải pháp khác cho điều này, miễn là bạn có một loại tham chiếu cho chuyển hướng. Trong một triển khai ngây thơ, bạn có thể sử dụng những điều sau đây cho các kiểu tùy ý.

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

Sau đó, theo ràng buộc mà bạn sẽ phải sử dụng ref.valueđể truy cập tham chiếu sau đó, bạn có thể viết whilevị ngữ của mình dưới dạng

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

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

và bạn có thể thực hiện việc kiểm tra chống lại bytesReadmột cách ẩn ý hơn mà không cần phải nhập nó.