Por lo que tengo entendido, en Scala podemos definir una función sin parámetros, ya sea usando paréntesis vacíos después de su nombre, o sin paréntesis, y estas dos definiciones no son sinónimos. ¿Cuál es el propósito de distinguir estas 2 sintaxis y cuándo debería usar mejor una en lugar de otra?¿Por qué usar paréntesis vacíos en Scala si no podemos usar paréntesis para definir una función que no necesita ningún argumento?
Es principalmente una cuestión de convención. Los métodos con listas de parámetros vacíos son, por convención, evaluados por sus efectos secundarios. Se supone que los métodos sin parámetros son libres de efectos secundarios. Esa es la convención.
Guía Scala Estilo dice omitir paréntesis sólo cuando el método se llama no tiene efectos secundarios: http://docs.scala-lang.org/style/method-invocation.html
Otras respuestas son grandes, pero también creo que vale la pena mencionar que los métodos no-param permiten buen acceso a unos campos de clases, así:
person.name
Debido a métodos sin parámetros, fácilmente se podría escribir un método para interceptar lee (o escribe) en el campo 'nombre' sin romper código de llamada, al igual que
def name = { log("Accessing name!"); _name }
Esto se llama el Uniform Access Principal
tengo otra luz para llevar a la utilidad de la convención fomentar un paréntesis vacíos bloquear en la declaración de funciones (y por tanto más tarde en las llamadas a ellos) con efectos secundarios.
Es con el depurador.
Si agrega un reloj en un depurador, como, por ejemplo, process refiriéndose por ejemplo a un booleano en el contexto de depuración enfocado, ya sea como una vista variable, o como una evaluación de función libre de efecto secundario pura, crea un riesgo desagradable para su solución de problemas posterior. De hecho, si el depurador mantiene ese reloj como una cosa de intentar evaluar cada vez que cambie el contexto (cambiar el hilo, mover en la pila de llamadas, llegar a otro punto de interrupción ...), que al menos encontré con IntelliJ IDEA, o Visual Studio para otros idiomas, entonces los efectos colaterales de cualquier otra función process posiblemente encontrada en cualquier alcance examinado serían activados ...
Imagínese el tipo de solución de problemas que esto podría ocasionar si lo hace no tener esa advertencia en mente, debido a algunos nombres inocentes y regulares. Si se aplicara la convención, con mi ejemplo, la evaluación booleana process nunca recurriría a una llamada a la función process() en los relojes del depurador; puede que solo esté permitido en su depurador acceder explícitamente a la función() poniendo process() en los relojes, pero entonces estaría claro que no está accediendo directamente a ningún atributo o variables locales, y recurrirá a otras funciones process() en otros ámbitos examinados, si tal vez con mala suerte, al menos sería menos sorprendente.
¿Qué harías, entonces, por un método de fábrica? ¿Escribirías 'def createAccount: Account' o' def createAccount(): Account'? – David
Para Scala completamente idiomático, los métodos de fábrica generalmente se escriben en el objeto complementario y se denominan "aplicar". Luego, puede crear objetos con la sintaxis especial para apply: Account (args). –
El compilador acepta redefinir las definiciones independientemente de las listas de parámetros vacías: http://pastie.org/1204728. Busque la cadena "lista de parámetros vacíos" en la Especificación del idioma. – mkneissl