Here are the slide decks and video for learning Scalaz talk:

• nescala2014_learning_scalaz.pdf
• video of the talk

Added day 21 on html5 book.

Added day 20 on html5 book.

Added day 19 on the html5 book.

Woke up early yesterday, so I started skimming @xuwei_k's override blog post. The topic was so intriguing, I got out of the bed and started translating it as the curious case of putting override modifier when overriding an abstract method in Scala. In there he describes the conundrum of providing the default instances to typeclasses by using Scalaz codebase as an example.

Here's a simplified representation of the problem:

trait Functor {
  def map: String
}
trait Traverse extends Functor {
  override def map: String = "meh"
}
sealed trait OneOrFunctor extends Functor {
  override def map: String = "better"
}
sealed trait OneOrTraverse extends OneOrFunctor with Traverse {
}
object OneOr {
  def OneOrFunctor: Functor = new OneOrFunctor {}
  def OneOrTraverse: Traverse = new OneOrTraverse {}
}

This is a translation of Scalaで抽象メソッドをoverrideする際にoverride修飾子を付けるべきかどうかの是非 by Kenji Yoshida (@xuwei_k), a Scalaz committer.

First, a quote from Programming in Scala, 2nd ed. p. 192:

Scala requires [override] modifier for all members that override a concrete member in a parent class. The modifier is optional if a member implements an abstract member with the same name.

In this post, we'll discuss this "The modififier is optional." Since overriding an existing method with implementation requires override modifier, and failure to do so would result to a compiler error, there's not much to talk about for that case. We'll focus on whether one should put override modifier or not in the case of overring an abtract method. I don't think there's going to be any difference in Scala version, but let's assume the latest stable 2.10.3.

In this post, I will discuss the execution semantics and task sequencing in sbt 0.13. First we will cover the background, and then I will introduce a new experimental plugin sbt-sequential that adds sequential tasks.

background

Mark said:

The sbt model is to have your side effects be local to your task so that as long as dependencies are satisfied, the task can be executed whenever. The win is parallel by default and enabling faster builds in practice.

In other words, with sbt, the build definitions only define the dependencies between the tasks. The timing at which these tasks are triggered is automatically calculated by sbt. To understand this, we should first look at the execution semantics of a Scala code with side effects.

Warning: This is a memo about sbt for intermediate users.

setting system

At the heart of sbt 0.13 is the setting system, just like sbt 0.12. Let's look at Settings.scala:

trait Init[Scope] {
  ...
 
  final case class ScopedKey[T](
    scope: Scope,
    key: AttributeKey[T]) extends KeyedInitialize[T] {
    ...
  }
 
  sealed trait Initialize[T] {
    def dependencies: Seq[ScopedKey[_]]
    def evaluate(map: Settings[Scope]): T
    ...
  }
 
  sealed class Setting[T] private[Init](
    val key: ScopedKey[T], 
    val init: Initialize[T], 
    val pos: SourcePosition) extends SettingsDefinition {
    ...
  }
}

If we ignore pos for now, a setting of T consists of the lhs key whose type is ScopedKey[T], and the rhs init whose type is Initialize[T].

I rebuilt tetrix in Scala series that I wrote last year into an html5 book using @n8han's Pamflet. I went through the git history commit by commit and upgraded the libraries and toolset to the state of the art as of 2013. This means multi-project build.sbt using sbt 0.13.0, Scala 2.10.2, every specs2 specs interpolated, and Akka 2.2.1 loaded on Android using pfn/android-sdk-plugin 1.0.6.

In addition, an extra day 13 was added for debugging and tuning up tetrix on Android.

• tetrix in Scala

How do you define oop?

purely object-oriented programming

Purely object-oriented programming is defined to be:

programming with objects.

What's an object?

It is an atom that can hold references to other objects, receive predefined list of messages, and send messages to other objects and itself; and nothing else. A message consists of a name and a list of reference to objects.

This is it. The wording is mine, but the idea is from Alan Kay (2003), the guy who coined the term object-oriented programming. Anything else is either not directly tied to oop or an implementation detail.