Scala's for-comprehensions: tính năng quan trọng hoặc cú pháp đường?

Question

Khi lần đầu tiên tôi bắt đầu nhìn vào Scala, tôi thích giao diện cho sự hiểu biết. Chúng dường như giống như các vòng lặp foreach mà tôi đã từng sử dụng từ Java 5, nhưng với các hạn chế về chức năng và rất nhiều tính độc đáo của cú pháp ngọt ngào.

Nhưng như tôi đã ghi nhận rõ phong cách Scala, tôi thấy rằng mỗi khi tôi có thể sử dụng một phi comprension Tôi đang sử dụng map, flatMap, filter, reduce và foreach để thay thế. Ý định của mã có vẻ rõ ràng hơn với tôi theo cách đó, với ít bất ngờ tiềm ẩn hơn, và chúng thường là mã ngắn hơn.

Theo như tôi biết, việc hiểu thấu đáo luôn được biên dịch thành các phương pháp này, vì vậy tôi tự hỏi: chúng thực sự là gì? Tôi có thiếu một số chức năng revalation (nó sẽ không phải là lần đầu tiên)? Do for-comprehensions làm một cái gì đó các tính năng khác có thể không, hoặc ít nhất sẽ được nhiều clumsier tại? Chúng có tỏa sáng trong một trường hợp sử dụng cụ thể không? Nó thực sự chỉ là vấn đề về sở thích cá nhân?

Answer 1

Vui lòng tham khảo this question. Câu trả lời ngắn gọn là để hiểu thấu hiểu có thể dễ đọc hơn. Đặc biệt, nếu bạn có nhiều máy tạo lồng nhau, phạm vi thực tế của những gì bạn đang làm trở nên rõ ràng hơn và bạn không cần thụt lề lớn.

Answer 2

cho hiểu là cú pháp đường, nhưng điều đó không có nghĩa là chúng không quan trọng. Chúng thường ngắn gọn hơn dạng mở rộng của chúng, điều này rất hay, nhưng có lẽ quan trọng hơn là chúng giúp các lập trình viên từ các ngôn ngữ mệnh lệnh sử dụng các cấu trúc chức năng.

Khi tôi lần đầu tiên bắt đầu với Scala tôi đã sử dụng để hiểu nhiều, bởi vì họ đã quen thuộc. Sau đó, tôi gần như dừng lại hoàn toàn, bởi vì tôi cảm thấy như sử dụng các phương pháp cơ bản rõ ràng hơn và do đó rõ ràng hơn. Bây giờ tôi trở lại sử dụng cho hiểu-hiểu vì tôi nghĩ rằng họ tốt hơn thể hiện ý định của những gì tôi đang làm chứ không phải là phương tiện làm việc đó.

Answer 3

Bạn nói đúng. Đối với hiểu là cú pháp đường. Tôi tin rằng các phương pháp cơ bản là gọn gàng hơn và dễ đọc hơn, một khi bạn đã quen với chúng.

Hãy so sánh những điều khoản tương đương sau:

1. for (i <- 1 to 100; if (i % 3 == 0)) yield Math.pow(i, 2) 
2. (1 to 100).filter(_ % 3 == 0).map(Math.pow(_, 2)) 

Theo tôi, việc bổ sung các dấu chấm phẩy trong # 1 sao lãng khỏi cảm giác rằng đây là một tuyên bố xích duy nhất. Ngoài ra còn có một cảm giác rằng tôi là một var (là nó 1, hoặc là nó 99, hoặc một cái gì đó inbetween?) Mà làm giảm từ một phong cách khác chức năng.

Tùy chọn 2 rõ ràng hơn là một chuỗi các cuộc gọi phương thức trên các đối tượng. Mỗi liên kết trong chuỗi rõ ràng nêu rõ trách nhiệm của nó. Không có biến trung gian.

Có lẽ để hiểu được bao gồm như là một sự tiện lợi cho các nhà phát triển chuyển đổi từ Java. Bất kể, được chọn là một vấn đề về phong cách và sở thích.

Answer 4

Một cách sử dụng tuyệt vời cho việc hiểu là dành cho DSL nội bộ. ScalaQL là một ví dụ tuyệt vời về điều này. Nó có thể tắt chức năng này

val underAge = for { 
    p <- Person 
    c <- Company 
    if p.company is c 
    if p.age < 14 
} yield p 

vào này

SELECT p.* FROM people p JOIN companies c ON p.company_id = c.id WHERE p.age < 14 

và nhiều thứ khác.

Answer 5

Trong một số trường hợp, để hiểu được có thể thể hiện ý định tốt hơn, do đó khi chúng thực hiện, hãy sử dụng chúng.

Cũng lưu ý rằng với tính năng hiểu, bạn sẽ nhận được mẫu phù hợp với miễn phí. Ví dụ, lặp lại trên một bản đồ đơn giản hơn nhiều với cho sự hiểu biết:

for ((key, value) <- map) println (key + "-->" + value)

hơn với foreach:

map foreach { case (key, value) => println (key + "-->" + value) }