15

So I'm learning Scala and I came across this finicky issue...

If we have a String and want to convert it to an Int, all examples that I've found online say, "It's so simple! Just use String.toInt!"

Okay:

var x = readLine().toInt

Simple enough. I'm assuming toInt is a function of String. But if that's the case, I should be able to call toInt with parentheses, right? Coming from Java, this feels more natural to me:

var x = readLine().toInt()

But alas! Scala gives me the following error:

[error] /home/myhome/code/whatever/hello.scala:13: Int does not take parameters

[error] var x = readLine().toInt()

Curious. What does this error mean? Is toInt not a function of String? Similarly, why can I do both:

var x = readLine().toLowerCase()
var y = readLine().toLowerCase

with out any problems?

Edit: The duplicate question does not address the toLowerCase vs toInt issue.

Kenny Worden
  • 4,335
  • 11
  • 35
  • 62
  • Possible duplicate of [What is the difference between def foo = {} and def foo() = {} in Scala?](http://stackoverflow.com/questions/7409502/what-is-the-difference-between-def-foo-and-def-foo-in-scala) – rogue-one Feb 18 '17 at 20:37

1 Answers1

20

This is a good question, and I don't think it counts as a duplicate of the question about defining zero-arity methods with or without parentheses.

The difference between toInt and toLowerCase here is that toInt is a syntactic enrichment provided by the standard library's StringOps class. You can check this by using reify and showCode in the REPL:

scala> import scala.reflect.runtime.universe.{ reify, showCode }
import scala.reflect.runtime.universe.{reify, showCode}

scala> showCode(reify("1".toInt).tree)
res0: String = Predef.augmentString("1").toInt

This just desugars the enrichment method call and shows you what implicit conversion has been applied to support it.

If we look at the toInt method on StringOps, we see that it's defined without parentheses. As the answer to the possible duplicate question points out, if a zero-arity method in Scala is defined without parentheses, it can't be called with parentheses (although if it's defined with parentheses it can be called either way).

So that's why "1".toInt() doesn't work. If String were a normal Scala class following normal Scala naming conventions, "ABC".toLowerCase() wouldn't work either, since the method would be defined without parentheses, since it's not side-effecting (this is just a convention, but it tends to be pretty consistently applied in Scala code).

The problem is that String isn't actually a class in the Scala standard library—it's just java.lang.String. At the JVM level, there's no difference between a zero-arity method defined with parentheses and one defined without parentheses—this is purely a Scala distinction, and it's not encoded in the JVM method signature, but in a separate batch of metadata stored in the class file.

The Scala language designers decided to treat all zero-arity methods that aren't defined in Scala (and therefore don't have this extra metadata) as if they were defined with parentheses. Since the toLowerCase method on String is really and truly a method of the java.lang.String class (not a syntactic enrichment method like toInt), it falls into this category, which means you can call it either way.

Community
  • 1
  • 1
Travis Brown
  • 138,631
  • 12
  • 375
  • 680
  • Thanks for your answer. So to bridge the gap in my understanding, a zero-arity method is a method that is defined without parentheses and these are only by convention (i.e. I can define a method that takes no arguments with parentheses to make it more Java-like)? So I would call a zero-arity method as if I was accessing a field? And if I use Java classes/libraries, there are no such thing as zero-arity methods? Also, what's a "side-effecting" method? – Kenny Worden Feb 18 '17 at 21:20
  • @KennethWorden I'm using "zero-arity" to refer to any method that doesn't take arguments, whether it's defined with or without parentheses. Java has methods that don't take arguments (and count as zero-arity in this sense), but it doesn't make a distinction between whether they're defined with parentheses or not (as a matter of Java syntax, they all are). – Travis Brown Feb 18 '17 at 21:24
  • And "side-effecting" here means that it's not a function in the mathematical sense—it may print something, return different values on subsequent calls, etc. – Travis Brown Feb 18 '17 at 21:25
  • 3
    I would expand a bit on how Travis explained "side-effecting", because it's really important and for someone coming from Java background it may not be that obvious. Function is side-effecting if it's performing some action that affects the "state of the world" outside of the function body in any way. That doesn't mean it has to be changing some values; it's enough that its effect is observable (e.g. printing to the console, as Travis said). This is bad. Another bad thing for a function is to keep some mutable state, which can result in different results being returned for same input arguments. – slouc Feb 18 '17 at 21:36
  • 2
    If a function has no side effects, depends only on its parameters and always returns the same result for same parameters, we call such function "pure". With zero-arity functions, we lose the condition of depending only on its parameters and returning always the same result for same parameters (since there are no parameters) so all we can potentially "mess up" is to have side effects. If we have none (no printing, no logging, no requests to anything, no database writes, etc.) then it's a safe, idempotent function - a simple getter, if you will - and by convention should have no parenthesis. – slouc Feb 18 '17 at 21:42