Scala – Understanding Parameterless and Empty-Paren Methods

scala

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.

Best Answer

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.

Related Solutions

Scala – Method Overloading Explained

Functions cannot be overloaded in Scala, that is correct. But println is not a function, it is a method, and methods most definitely can be overloaded.

I'm not sure what you mean by "How it is done". It is done the exact same way that you do it in every other language that supports overloading. If you want two definitions of a method with different types you write two definitions with different types:

def foo(arg: Int)    { println("I am overloaded for Int.")    }
def foo(arg: String) { println("I am overloaded for String.") }

foo(42)
// I am overloaded for Int.

foo("Hello")
// I am overloaded for String.

foo(1.0)
// error: overloaded method value foo with alternatives:
//  (arg: String)Unit <and>
//  (arg: Int)Unit
// cannot be applied to (Double)
//                  foo(1.0)
//                  ^

The reason why function overloading isn't supported is simple: technically speaking, the term doesn't even make sense, since "overloading" basically means (very broadly) "different bindings for the same name depending on context". But functions don't have a name, so the whole concept of having different implementations bind to the same name is nonsensical.

Scala Infix Notation – How to Use It

Starting with version 2.10, Scala introduced implicit Classes to handle precisely this issue.

This will perform an implicit conversion on a given type to a wrapped class, which can contain your own methods and values.

In your specific case, you'd use something like this:

implicit class RichInt(x: Int) {
  def isAFactorOf(y: Int) = x % y == 0
}

2.isAFactorOf(10)
// or, without dot-syntax
2 isAFactorOf 10

Note that when compiled, this will end up boxing our raw value into a RichInt(2). You can get around this by declaring your RichInt as a subclass of AnyVal:

implicit class RichInt(val x: Int) extends AnyVal { ... }

This won't cause boxing, but it's more restrictive than a typical implicit class. It can only contain methods, not values or state.

Best Answer

Related Solutions

Scala – Method Overloading Explained

Scala Infix Notation – How to Use It

Related Topic