The Artima Developer Community


Errata for Programming in Scala, 4th Edition
Chapter: All
Return to errata index.

Page xxxvi (PDF page 36):
Third paragraph, last sentence: "and Scala 2 will *BE* continue to be the
de facto..."
---
Fixed in later 4ed printing. Tnx.
Page 56 (PDF page 94):
The first line (output of the countchars1.scala) program doesn't include
the .toString call in Listing 3.10
----
This issue went away in 5ed because we replaced that section with one
about map and for-yield.
Page 83 (PDF page 121):
4ed OReilly Safari (also on page 121 in paperback, 3ed):

"For example, Listing 7.4 shows an alternate way to determine a
greatest common divisor of two numbers."

I guess it should say "the greatest common divisor"; there might be a
number of divisors, but only one can be the greatest.
Page 88 (PDF page 126):
Line 3: "short-ciruit" insted of "short-circuit"
Page 88 (PDF page 126):
Found on Safari online, 4th ed (also on page 88 of paperback 3rd ed):

"but don't short-ciruit like && and ||."

should be:

"but don't short-circuit like && and ||."
Page 100 (PDF page 138):
6.3 => The hex id of the object doesn't match

Fixed in 5ed.
Page 120 (PDF page 158):
"and captures to greet's unit value result, ()."
it should say:
"and captures the greet's unit value result, ()."

Fixed in 5ed. Tnx.
Page 127 (PDF page 165):
On O'Reilly Safari 4ed:

"This **Array[String]** containing lines is transformed into another
Array[String] containing only trimmed lines that include the substring
"for"."

First appearance of Array[String] uses the wrong font, should use
mono-spaced font.
Page 129 (PDF page 167):
O'Reilly Safari, 4ed (also on page 129, paperback 3ed):

"You can wrap an expression with a finally clause if you want to cause
some code to execute no matter how the expression terminates."

Not really an errata, but a bit misleading. It probably should say "You
can wrap a try-catch expression..." as in the previous paragraph. Or even
better "a try-expression" in both cases, AFAIK catch and finally are
optional clauses subsidiary to a try-expression.
Page 158 (PDF page 196):
On Safari, 4ed:

Section on Repeated parameters

"Nevertheless, if you have an *array* of the appropriate type,.. "

It is actually a seq or sequence, not an array.

"To accomplish this, you'll need to append the *array* argument with.. "

Ditto here.

----
Fixed in 5ed. Tnx.
Page 232 (PDF page 270):
Based on the superclass:

//from page: 222
abstract class Element {
  def contents: Array[String]
  val height = contents.length
  val width = if (height == 0) 0 else contents(0).length
}

The book goes on to extend with another sub-class:

class UniformElement(
                    ch: Char,
                    override val width: Int,
                    override val height: Int
                    ) extends Element {
  private val line = ch.toString * width
  def contents = Array.fill(height)(line)
}

This causes a null-pointer exception in the Scala REPL.

I found that others also get trapped on this, possibly from older
versions of the book:
 -
https://stackoverflow.com/questions/42312232/npe-in-using-scala-array-fill
/42312929
 -
https://html.developreference.com/article/22372654/Scala+companion+object+
with+abstract+class

----
I added a footnote that clarifies which version of Element UniformElement
should extend, which is the one in Listing 10.2. If you do that, the NPE
doesn't happen.
Page 251 (PDF page 289):
Listing 10.6 - Invoking a superclass constructor.
it should revise to:

class LineElement(s: String) extends ArrayElement(Array(s)) {
  override val width = s.length
  override val height = 1
}


,not :

class LineElement(s: String) extends ArrayElement(Array(s)) {
override def width = s.length
override def height = 1
}

,otherwise it would report like this:

On line 2: error: stable, immutable value required to override:
       val width: Int (defined in class Element)
       	override def height = 1
                            ^
On line 3: error: stable, immutable value required to override:
       val height: Int (defined in class Element)

-----
The issue is from extending the wrong version of Element. I added
comments to clarify in 5ed. Tnx.
Page 305 (PDF page 343):
Listing 15.22 says

def show(e: Expr) = s"${println(f.format(e))}\n\n"

But since "\n\n" is not part of the String passed to function println, it
won't produce the line-spacing between expressions shown on page 306.

The code below seems more accurate:

def show(e: Expr) = println(s"${f.format(e)}\n\n")

----
Fixed in 5ed. Tnx.
Page 587 (PDF page 625):
First line of subtractOne function, the last prev statement is redundant,
because the last statement of the function returns "this". Possibly, the
"else" block needs braces. I haven't worked out the code yet.
---
I found some other issues also, and made a TODO to fix in 5ed Advanced.
Tnx for reporting.
Page 615 (PDF page 653):
Scala provides the @scala.reflect.BeanProperty
annotation. If you add this annotation to a field, the compiler will
automatically generate get and set methods for you.

BeanProperty is in scala.beans package.
---
Fixed in 5ed. Tnx.
Page 646 (PDF page 684):
"For value types, == is value comparison, just
like in Java. For reference types, == is the same as equals in Scala."

I wonder if it shouldnt be:
"is the same as equals in Java."
---
Reworked to make it clearer in 5ed. We did mean in Scala, but meant == in
Scala not equals in Scala.
Page 653 (PDF page 691):
Automatic get and set methods:
@scala.reflect.BeanProperty is wrong. @scala.beans.BeanProperty is true
---
Fixed in 5ed. Tnx.
Page 701 (PDF page 739):
SECTION:
Combining futures: zip, Future.foldLeft, Future.reduceLeft,
Future.sequence, and Future.traverse

Page 739, 740

Still use TraversableOnce (not included in the Scala 2.13 collection
framework) rather then the right IterableOnce in this section.
---
Fixed in 5ed. Tnx.
Page 1082 (PDF page 1120):
I think there is an issue with the code sample involving iterators
and dropwhile.

scala> val it = Iterator("a", "number", "of", "words")
it: Iterator[java.lang.String] = <iterator>
  
scala> it dropWhile (_.length < 2)
res4: Iterator[java.lang.String] = <iterator>
  
scala> it.next()
res5: java.lang.String = number

The book states that after the call to dropWhile, the iterator "it"
points to "number". This is not the case when I run this code in the
Scala REPL or in a script. It instead points to "a". It looks like the
call creates an independent iterator which points to "number". I
wrote this to verify:
val it2 = it dropWhile (_.length < 2)                                    
                          
println(it2.next())   // prints "number"

----
True. Fixed this in 5ed. Tnx.

Copyright © 2021 Artima, Inc. All rights reserved.