Przyjąłem twoje pytanie, dlaczego nie zaprojektować języka, aby w pierwszej kolejności uniknąć konieczności zjazdu? Innymi słowy, dlaczego Scala nie wymusza po prostu używania nawiasów przez cały czas, zamiast pozwolić programistom czasami je pomijać?
Odpowiedź znajduje się w przejrzystości referencyjnej . Zasadniczo, jeśli funkcja nie ma skutków ubocznych, wywołanie funkcji można zastąpić wynikiem, bez zmiany zachowania programu.
Oznacza to, że funkcja bez parametrów lub skutków ubocznych jest semantycznie równoważna z valwartością zwrotną tej funkcji. Ze względu na tę właściwość, w miarę ewolucji klasy, programista może przełączać się pomiędzy używaniem a vallub używaniem funkcji, jak wymaga tego wygoda lub wydajność.
Ponieważ możesz pominąć nawiasy, oznacza to, że wywoływanie kodu coś takiego queue.sizenie musi wiedzieć ani przejmować się, czy sizejest funkcją czy val. Implementator Queueklasy może więc swobodnie zmieniać między nimi bez konieczności zmiany kodu wywołującego (chociaż uważam, że będzie to wymagało ponownej kompilacji). Stabilizuje interfejs publiczny klasy. Na przykład możesz zacząć queue.sizeod wywołania sizeinstrumentu bazowego List, który jest potencjalnie O(n), a następnie zmienić sizena a valze względu na wydajność.
Konwencja sugeruje nawiasy, gdy występują skutki uboczne, aby wyjaśnić, że ten element klasy jest zdecydowanie wywołaniem funkcji, a zatem potencjalnie nie jest referencyjnie przejrzysty. Ważne jest, aby wywoływać kod, aby wiedzieć, czy występują działania niepożądane, aby mogli uniknąć wielokrotnego wywoływania go. Jeśli nie obchodzi cię, czy jest to funkcja, czy nie, równie dobrze możesz potraktować ją, jakby nie była.
