Search Results

One more benefit is that objects can implement interfaces/traits, unlike static methods.

Yes, it is considered okay in general. A relatively common use is to initialize fields of a supertype when they have to depend on the state of a subtype (but even there you need to be careful). See ht …

I wouldn't consider this to be a violation of the open-closed principle: because the trait is sealed, the relevant entity isn't just Person, but Person together with its implementations, and isn't ope …

No, you just use futures and don't call get on them unless absolutely necessary. Instead, you add callbacks to the futures and transform and compose futures with combinators. See Twitter Util futures …

Many Scala idioms and approaches are derived from Haskell, and so it pays a lot of attention to type-safety, monads, etc. … (eg Monoids) (Now I realise there is an STM in Scala, and that Actor models, Avout and Cascalog are wonderful exceptions to this - I'm making a generalisation) Better example of this in Clojure core …

Sharing is only part of the answer. The mutable map has to contain all the fields which will be needed when/if elements are added, since calling methods can't change the class of the object. With im …

is there any Scala-specific reason why this style is common in our codebase? … No, it is entirely orthogonal to use of Scala; if I had to guess, I would be pretty sure that such separation is more popular in Java. …

As a simple demonstration why function input types can't be covariant, with no mutability involved (using Scala syntax): val f: Int => Int = x => 2 * x val g: Any => Int = f // allowed by covariance …

Instead of pattern matching explicitly, you can write .getOrElse { throw new IllegalStateException("Failed to load answer after creation") } More generally, when dealing with Option/Either/Try you …

In Scala you have a better option: using algebraic types for return values such as Option[T], Either[Exception, T], your own type when you want the user to handle specific cases (e.g. instead of def foo … FooResult and the consumer now is required to handle all results) For dealing with external code which does throw exceptions, you have scala.util.control.exception or scala.util.Try (starting with Scala …

No, Scala is obviously not a Lisp dialect in any meaningful sense. If you look at what he says: I mention this mostly as a joke, but it is quite true. … So, you can write a dialect of Lisp based on Scala, perhaps even as an internal DSL, but that doesn't mean that all Scala programs will belong to this dialect. …

In this case using QuickCheck (for Haskell) or ScalaCheck (for Scala) can let you write down these properties as expressions of the language and check that they hold for random inputs. …

Also, you should be able to assign Scala lambdas (i.e. x => ...) to Function and any other SAM types in Scala 2.11, and Java 8 lambdas to Function1. … (EDIT: this actually got added in Scala 2.12, not 2.11.) …