Zrozumienie Scali: ważna cecha czy cukier syntaktyczny?

Question

Kiedy po raz pierwszy zacząłem patrzeć na Scalę, podobał mi się wygląd pojęć. Wydawało się, że są trochę podobne do pętli foreach, z których byłem przyzwyczajony w Javie 5, ale z ograniczeniami funkcjonalnymi i mnóstwem słodkiej sławy syntaktycznej.

Ale jak już wchłonął stylu Scala, uważam, że za każdym razem mogę używać For-comprension używam map, flatMap, filter, reduce i foreach zamiast. Intencja kodu wydaje mi się w ten sposób bardziej przejrzysta, z mniejszymi potencjalnymi ukrytymi niespodziankami, a także z reguły krótszym kodem.

O ile mi wiadomo, do-zrozumienia zawsze są kompilowane w dół do tych metod, tak więc zastanawiam się: po co właściwie są? Czy brakuje mi jakiejś rewaloryzacji funkcjonalnej (nie byłby to pierwszy raz)? Czy do zrozumienia rozumie się coś, czego inne funkcje nie potrafią, a przynajmniej nie są bardziej niezgrabne? Czy świecą w konkretnym przypadku użycia? Czy to naprawdę tylko kwestia osobistego gustu?

Answer 1

Proszę odnieść się do this question. Krótka odpowiedź brzmi, że zrozumienie może być bardziej czytelne. W szczególności, jeśli masz wiele zagnieżdżonych generatorów, rzeczywisty zakres tego, co robisz staje się jaśniejszy i nie potrzebujesz dużych wcięć.

Answer 2

dla zrozumienia są cukrem syntaktycznym, ale to nie znaczy, że nie są istotne. Zwykle są one bardziej zwięzłe niż ich rozwinięta forma, co jest miłe, ale być może ważniejsze jest to, że pomagają programistom z imperatywnych języków używać konstruktów funkcjonalnych.

Kiedy zacząłem od Scali, często używałem do zrozumienia, ponieważ były one znane. Wtedy prawie całkowicie się zatrzymałem, ponieważ czułem, że użycie podstawowych metod było bardziej jednoznaczne, a przez to wyraźniejsze. Teraz wracam do korzystania z objaśnień, ponieważ myślę, że lepiej wyrażają intencję tego, co robię, niż sposób robienia tego.

Answer 3

Masz rację. For-Comprehension to cukier syntaktyczny. Uważam, że podstawowe metody są bardziej lapidarne i łatwiejsze do odczytania, gdy już się do nich przyzwyczaisz.

Porównaj następujące równoważne sprawozdań:

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

moim zdaniem dodanie średnikiem w # 1 odrywa od poczucia, że ​​jest to pojedynczy łańcuch stwierdzenie. Istnieje również poczucie, że ja jest var (czy jest to 1, czy to 99, czy coś pomiędzy?), Co niweczy w przeciwnym razie funkcjonalny styl.

Opcja 2 jest bardziej oczywistym łańcuchem wywołań metod na obiektach. Każde ogniwo łańcucha wyraźnie określa swoją odpowiedzialność. Nie ma zmiennych pośrednich.

Być może dla zrozumienia są włączone jako udogodnienie dla programistów przechodzących z Java. Niezależnie od tego, która jest wybrana, jest kwestią stylu i preferencji.

Answer 4

Innym doskonałym zastosowaniem do zrozumienia jest wewnętrzny DSL. ScalaQL jest tego świetnym przykładem. Można go włączyć tę

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

w tym

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

i wiele więcej.

Answer 5

W niektórych przypadkach ze zrozumieniem można lepiej wyrazić zamiar, więc kiedy to zrobi, użyj ich.

Należy również pamiętać, że dla celów ze zrozumieniem, otrzymasz wzór pasujący do za darmo. Na przykład, iteracja na mapie jest znacznie prostsze do zrozumienia z:

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

niż foreach:

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