12

I'm learning Scala at the moment via Odersky's Programming Scala (2nd). I'm upto chapter 10 where he starts introducing parameterless and empty-paren methods. I just can't get my head around it.

So far, all I understand is that I should use empty-parens if a method has side-effects and parameterless methods otherwise.

I can't figure out what is the advantage of this convention. I read the posts on Stack Exchange, but to be honest, when the posts start discussing this topic in some depth I was lost.

I'm looking for a simple explanation of what are typical use cases for this language feature and what are the advantages to help me understand it better.

0

2 Answers 2

15

I took your question as why not design the language to prevent the need for a convention in the first place? In other words, why doesn't Scala just force the use of parentheses all the time, instead of allowing programmers to omit them sometimes?

The answer is found in referential transparency. Essentially, if a function has no side effects, a function call can be replaced with its result, without changing the behavior of the program.

That means a function without parameters or side effects is semantically equivalent to a val holding the return value of that function. Because of this property, as a class evolves, the programmer might switch back and forth between using a val or using a function, as convenience or efficiency dictates.

Since you can omit the parentheses, that means code calling something like queue.size doesn't need to know nor care if size is a function or a val. The implementer of the Queue class is therefore free to change between the two without having to change any of the calling code (although I believe it will need recompiling). It stabilizes the public interface of the class. For example, you might start out a queue.size by calling size on an underlying List, which is potentially O(n), then change size to a val for reasons of efficiency.

The convention suggests the parentheses when there are side effects to make it clear that this class member is definitely a function call, and therefore potentially not referentially transparent. It's important for calling code to know if side effects are produced, so they can avoid calling it repeatedly. If you don't care whether it's a function or not, you may as well treat it as if it's not.

6

That is a convention, not part of the language design. It is used as a signpost to help the folks who have to read the code after you write it to understand it better.

From Scala's Style Guide on Method Invocation:

Scala allows the omission of parentheses on methods of arity-0 (no arguments):

reply() 

// is the same as 

reply

However, this syntax should only be used when the method in question has no side-effects (purely-functional). In other words, it would be acceptable to omit parentheses when calling queue.size, but not when calling println().

Religiously observing this convention will dramatically improve code readability and will make it much easier to understand at a glance the most basic operation of any given method. Resist the urge to omit parentheses simply to save two characters!

In .NET, the convention is to use methods when the code can take awhile to run (say, longer than 50ms), and properties (essentially empty-paren methods) when it won't (i.e. it is a simple lookup).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.