Programming in Scala Quotes

“The compiler requires that you invoke parameterless methods defined in Scala 3 without empty parentheses and empty-parens methods defined in Scala 3 with empty parentheses.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“On the other hand, you should never define a method that has side-effects without parentheses, because invocations of that method would then look like a field selection. So your clients might be surprised to see the side effects.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“In principle it's possible to leave out all empty parentheses in calls to functions defined in Java or Scala 2. However, it's still recommended to write the empty parentheses when the invoked method represents more than a property of its receiver object. For instance, empty parentheses are appropriate if the method performs I/O, writes reassignable variables (vars), or reads vars other than the receiver's fields, either directly or indirectly by using mutable objects. That way, the parameter list acts as a visual clue that some interesting computation is triggered by the call.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“withPrintWriter(file) { writer =>
writer.println(new java.util.Date)
}”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“loan pattern,”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“def plainOldSum(x: Int, y: Int) = x + y
plainOldSum(1, 2) // 3
Listing 9.2 - Defining and invoking a "plain old" function. By contrast, Listing 9.3 shows a similar function that's curried. Instead of one list of two Int parameters, you apply this function to two lists of one Int parameter each. def curriedSum(x: Int)(y: Int) = x + y
curriedSum(1)(2) // 3”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“you could just write (fileName, query) => fileName.endsWith(query). Since the parameters are each used only once in the body of the function (i.e., the first parameter, fileName, is used first in the body, and the second parameter, query, is used second), you can use the placeholder syntax: _.endsWith(_). The first underscore is a placeholder for the first parameter, the file name, and the second underscore a placeholder for the second parameter, the query string.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“The function literal _.endsWith(_), used in the filesEnding method, means the same thing as: (fileName: String, query: String) => fileName.endsWith(query)”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“Note that _ + _ expands into a literal for a function that takes two parameters. This is why you can use this short form only if each parameter appears in the function literal exactly once. Multiple underscores mean multiple parameters, not reuse of a single parameter repeatedly. The first underscore represents the first parameter, the second underscore the second parameter, the third underscore the third parameter, and so on.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“One problem with this approach is that all the helper function names can pollute the program namespace. In the REPL this is not so much of a problem, but once functions are packaged in reusable classes and objects, it's desirable to hide the helper functions from clients of a class. They often do not make sense individually, and you often want to keep enough flexibility to delete the helper functions if you later rewrite the class in a different way. In”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“an important design principle of the functional programming style: programs should be decomposed into many small functions that each do a well-defined task. Individual functions are often quite small. The advantage of this style is that it gives a programmer many building blocks that can be flexibly composed to do more difficult things. Each building block should be simple enough to be understood individually.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“We factored out the two helper functions, makeRow and makeRowSeq, to make the code easier to read.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“You may have noticed that there has been no mention of break or continue. Scala leaves out these commands because they do not mesh well with function literals, a feature described in the next chapter. It is clear what continue means inside a while loop, but what would it mean inside a function literal? While Scala supports both imperative and functional styles of programming, in this case it leans slightly towards functional programming in exchange for simplifying the language.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“For example, given this, rather contrived, function definition: def f(): Int = try return 1 finally return 2
calling f() results in 2. By contrast, given: def g(): Int = try 1 finally 2
calling g() results in 1. Both of these functions exhibit behavior that could surprise most programmers, so it's usually best to avoid returning values from finally clauses.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“As in Java, if a finally clause includes an explicit return statement, or throws an exception, that return value or exception will "overrule" any previous one that originated in the try block or one of its catch clauses.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“The result is that of the try clause if no exception is thrown, or the relevant catch clause if an exception is thrown and caught. If an exception is thrown but not caught, the expression has no result at all. The value computed in the finally clause, if there is one, is dropped. Usually finally clauses do some kind of clean up, such as closing a file. Normally, they should not change the value computed in the main body or a catch clause of the try.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“One difference you'll quickly notice in Scala is that, unlike Java, Scala does not require you to catch checked exceptions or declare them in a throws clause. You can declare a throws clause if you wish with the @throws annotation, but it is not required.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“As of Scala 3, Scala no longer offers a do-while loop, a looping control structure that tested the condition after the loop body instead of before. Instead, you can place the statements of the loop body first after while, finish with the boolean condition, and follow that with a "do ()".”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“It is called the unit value and is written (). The existence of () is how Scala's Unit differs from Java's void.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“You can create extension methods on Int that take rational numbers. Try adding these lines in the REPL: extension (x: Int)
def + (y: Rational) = Rational(x) + y
def - (y: Rational) = Rational(x) - y
def * (y: Rational) = Rational(x) * y
def / (y: Rational) = Rational(x) / y”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“Scala, constructors other than the primary constructor are called auxiliary constructors”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“class Rational(n: Int, d: Int):
require(d != 0)
override def toString = s"$n/$d"
The require method takes one boolean parameter. If the passed value is true, require will return normally. Otherwise, require will prevent the object from being constructed by throwing an IllegalArgumentException.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“In Java, classes have constructors, which can take parameters; whereas in Scala, classes can take parameters directly.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“class parameters. The Scala compiler will gather up these two class parameters and create a primary constructor that takes the same two parameters.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“Nevertheless, it is good style to use parentheses to clarify what operators are operating upon what expressions. Perhaps the only precedence you can truly count on other programmers knowing without looking up is that multiplicative operators, *, /, and %, have a higher precedence than the additive ones + and -”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“However, eq and its opposite, ne, only apply to objects that directly map to Java objects.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“First check the left side for null. If it is not null, call the equals method.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“println("""|Welcome to Ultamix 3000.
|Type "HELP" for help.""".stripMargin)”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“However, given that all the members of package scala and java.lang are automatically imported into every Scala source file, you can just use the simple names (i.e., names like Boolean, Char, or String) everywhere.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“One difference between Scala and Java is that whereas Java requires you to put a public class in a file named after the class—for example, you'd put class SpeedRacer in file SpeedRacer.java—in Scala, you can name .scala files anything you want, no matter what Scala classes or code you put in them. In general in the case of non-scripts, however, it is recommended style to name files after the classes they contain as is done in Java, so that programmers can more easily locate classes by looking at file names.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0