Scala Issues Subscribe Pub

Consolidated blog first published on

Scala is a new and promising programming language which compiles to JVM byte code and it is touted as a replacement for Java. However, it has a functional and scripting background and there are some things that may surprise you, especially if you come from a Java background...basically, "Here be dragons"...

If you're new to Scala, here's some great links to get you started:

foo is not the same as foo()

scala> def foo = new { def apply() = "not foo really" }
foo: java.lang.Object{def apply(): java.lang.String}

scala> foo()
res0: java.lang.String = not foo really

Not what you'd expect. Basically a function defined without () must be invoked without (), while a function defined with () can be invoked without (). The side-effects are many, as the example above demonstrates.

Here's more details:

strict vs non-strict

Many scala collections and constructs are non-strict, especially Range.

Be very careful with this type of statement, in versions prior to scala 2.8:

object LearnStrict extends Application {
   var prefix = "expected-"
   val list = for (i <- 0 to 3) yield prefix + i*i
   prefix = "UNEXPECTED-1-"
   println (list mkString)
   prefix = "UNEXPECTED-2-"
   println (list mkString)

The result is different than what you'd expect...reason being that for is not a loop. for simply delegates to a method named "foreach" or "map" on the subject collection and the implementation for those, on many collections, are not strict - meaning they will evaluate more than once...

The Range has been changed in scala 2.8 - now it's strict, meaning the range (0 to 3) will evaluate only once. However, beware of other collections...

A simple fix is to force the collection toList:

val list = (for (i <- 0 to 3) yield prefix + i*i).toList

Bottom line...remember that for (e <- elements) it is NOT THE SAME as java's for (e : elements). Especially when you're dealing with threads...

IF you want to see some very funny behavior, replace the for with this innocent-looking one:

val list = for (i <- Map ("1"->"a","2"->"b", "3"->"c").values) yield prefix + i

class parameters: members or not?

Class parameters are not always members... and it's not easy to figure out if they will be members or just arguments for the primary constructor...

The rules are that if they're marked with "val" or "var" OR the class is a case class, then they ARE class members. If that doesn't apply, then they MAY be class members, if needed later on in the class.

For instance, in this example in section 6.3 of the scala bible, the two must end up as members:

class Rational(n: Int, d: Int) {
  override def toString = n +"/"+ d

While in this example in section 6.6, they should not...

class Rational(n: Int, d: Int) {
  require(d != 0)
  val numer: Int = n
  val denom: Int = d
  override def toString = numer +"/"+ denom

What to do? Use VAL as much as possible. If you just can't, tread lightly! See more details at

The best ilustration was given to me by Daniel Sobral: contrast this version:

class LargePerson(name:String, age:Int) = {
 override def toString = name + ", aged: " + age

with this one:

class SmallPerson(name: String, age: Int) = {
  override val toString = name + ", aged: " + age

switch/case fall-through

Although there's a debate about fall-back and fall-through, in principle, if you wanted to do the equivalent of java's:

switch (value) {
   case 1 : 
   case 2 :

You can use the OR operator, in Scala:

value match {
   case 1 | 2 => do1

null acting funny

This generates a compile error:

class NoStatic[T<:AnyRef] {
   var lazyValue = null

while this works fine:

class NoStatic[T>:Null<:AnyRef] {
   var lazyValue = null

The trick is that while null is an instance of AnyRef, it is not an instance of T<:AnyRef, which could be Nothing...

...Yeah, I know...

Mind your type parameters

Type parameters overwrite each-other in a class the same way values/variables would. In the example below, the [A] used in the method foreach is not the same [A] as the one used in the rest of the class Cont[A].

class Cont[A] {
   def foreach[A](f: A => Unit) {}

trait Goo {}

class kuku extends Cont[Int] {
   override def foreach[Goo](f: Goo => Unit) {}

The correct version is:

   def foreach(f: A => Unit) {}

Was this useful?    

By: Razie | 2014-11-03 .. 2017-05-05 | Tags: post , scala , programming

See more in: Cool Scala Subscribe

Viewed 1094 times ( | Print ) this page.

You need to log in to post a comment!