Зачем использовать пустые скобки в Scala, если мы можем просто использовать без скобок для определения функции, которая не нуждается в аргументах?

Question

Насколько я понимаю, в Scala мы можем определить функцию без параметров либо с помощью пустых скобок после ее имени, либо вообще без скобок, и эти два определения не являются синонимами. Какова цель различения этих двух синтаксисов и когда мне лучше использовать один вместо другого?

Answer 1

Это в основном вопрос соглашения.По соглашению методы с пустыми списками параметров оцениваются на предмет их побочных эффектовПредполагается, что методы без параметров не имеют побочных эффектов.Это соглашение.

Answer 2

В Scala Style Guide говорится, что опускайте скобки только в том случае, если вызываемый метод не имеет побочных эффектов: http://docs.scala -lang.org / style / method-invocation.html

Answer 3

Другие ответы хороши, но я также думаю, что стоит упомянуть, что методы без параметров предоставляют хороший доступ к полям классов, например:

person.name

Из-за методов без параметров вы можете легко написатьметод для перехвата чтения (или записи) в поле «имя» без прерывания вызывающего кода, например

def name = { log("Accessing name!"); _name }

Это называется Принцип унифицированного доступа

Answer 4

У меня есть еще один свет, чтобы подчеркнуть полезность соглашения, поощряющего пустой блок скобок в объявлении функций (и, следовательно, в вызовах к ним) с побочными эффектами.

Это с отладчиком .

Если добавить часы в отладчике, например, например, process, ссылаясь на пример на логическое значение в фокусированном контексте отладки, либо в виде представления переменной, либо в качестве оценки функции без побочных эффектов, это создает неприятный риск для последующего устранения неисправностей. В самом деле, если отладчик сохраняет эти часы как попытку попытаться оценить каждый раз, когда вы меняете контекст (изменение потока, перемещение в стеке вызовов, достижение другой точки останова ...), что, как я обнаружил, было, по крайней мере, в случае с IntelliJ IDEA или Visual Studio для других языков, тогда побочные эффекты любой другой функции process, возможно, обнаруженной в любой области просмотра, будут вызваны ...

Только представьте, какой загадочный способ устранения неполадок может привести к тому, что вы просто не будете иметь в виду это предупреждение из-за невинных регулярных имен. Если бы соглашение было приведено в исполнение, в моем примере логическое вычисление process никогда бы не вернулось к вызову функции process() в наблюдениях отладчика; в вашем отладчике может быть просто разрешен явный доступ к функции (), помещающей process() в часы, но тогда будет ясно, что вы не имеете прямого доступа ни к какому атрибуту или локальным переменным, а к другим функциям process() в других случаях просмотренные области, если возможно не повезет, будут, по крайней мере, очень менее удивительными.