30

As far as I understand, in Scala we can define a function with no parameters either by using empty parentheses after its name, or no parentheses at all, and these two definitions are not synonyms. What is the purpose of distinguishing these 2 syntaxes and when should I better use one instead of another?

Ivan
  • 63,011
  • 101
  • 250
  • 382

4 Answers4

46

It's mostly a question of convention. Methods with empty parameter lists are, by convention, evaluated for their side-effects. Methods without parameters are assumed to be side-effect free. That's the convention.

Dave Griffith
  • 20,435
  • 3
  • 55
  • 76
  • What would you do, then, for a factory method? Would you write `def createAccount: Account` or `def createAccount(): Account`? – David Oct 07 '10 at 01:53
  • 7
    For fully idiomatic Scala, factory methods are usually written on the companion object, and are named "apply". Then, you can create objects with the special syntax for apply: Account(args). – Dave Griffith Oct 07 '10 at 03:09
  • The compiler accepts overriding definitions regardless of empty parameter lists: http://pastie.org/1204728 . Look for the string "empty parameter list" in the Language Specification. – mkneissl Oct 07 '10 at 06:29
  • 1
    mkneissel is correct - you can override both ways between `method()` and `method`. You can only override a `val` with another `val`, however, and `method()()` is considered different (for the purposes of overriding, but not for name collisions) from `method()` and `method`. – Rex Kerr Oct 07 '10 at 18:07
  • Also, http://stackoverflow.com/questions/12334936/why-does-scala-need-parameterless-in-addition-to-zero-parameter-methods/12340289#12340289 – som-snytt Nov 02 '16 at 22:15
  • So idempotent methods shouldn't have `()` – Janac Meena Jan 16 '19 at 19:59
15

Scala Style Guide says to omit parentheses only when the method being called has no side-effects: http://docs.scala-lang.org/style/method-invocation.html

Channing Walton
  • 3,977
  • 1
  • 30
  • 59
Alain O'Dea
  • 21,033
  • 1
  • 58
  • 84
1

Other answers are great, but I also think it's worth mentioning that no-param methods allow for nice access to a classes fields, like so:

person.name

Because of parameterless methods, you could easily write a method to intercept reads (or writes) to the 'name' field without breaking calling code, like so

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

This is called the Uniform Access Principal

Adam Rabung
  • 5,232
  • 2
  • 27
  • 42
0

I have another light to bring to the usefulness of the convention encouraging an empty parentheses block in the declaration of functions (and thus later in calls to them) with side effects.

It is with the debugger.

If one add a watch in a debugger, such as, say, process referring for the example to a boolean in the focused debug context, either as a variable view, or as a pure side-effect free function evaluation, it creates a nasty risk for your later troubleshooting. Indeed, if the debugger keeps that watch as a try-to-evaluate thing whenever you change the context (change thread, move in the call stack, reach another breakpoint...), which I found to be at least the case with IntelliJ IDEA, or Visual Studio for other languages, then the side-effects of any other process function possibly found in any browsed scope would be triggered...

Just imagine the kind of puzzling troubleshooting this could lead to if you do not have that warning just in mind, because of some innocent regular naming. If the convention were enforced, with my example, the process boolean evaluation would never fall back to a process() function call in the debugger watches; it might just be allowed in your debugger to explicitly access the () function putting process() in the watches, but then it would be clear you are not directly accessing any attribute or local variables, and fallbacks to other process() functions in other browsed scopes, if maybe unlucky, would at the very least be very less surprising.

Nirvana
  • 93
  • 1
  • 6