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.
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.
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.
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.
I've been thinking about exploring a subset of Scala in a wonderland setting without the "real world" constraints such as Java familiarity and interoperability. If using Scala as an alternative Java is acceptable, why not try using it as an alternative functional programming language? Another point of this thought experiment is to see some of the duplicate constructs can be reduced. In this article, I'm not interested in finding out the idiomatic way, or calling something good or bad. I'm calling this The Flying Sandwich Parts (TFSP).