Luet oppimateriaalin englanninkielistä versiota. Mainitsit kuitenkin taustakyselyssä osaavasi suomea. Siksi suosittelemme, että käytät suomenkielistä versiota, joka on testatumpi ja hieman laajempi ja muutenkin mukava.

Suomenkielinen materiaali kyllä esittelee englanninkielisetkin termit.

Kieli vaihtuu A+:n sivujen yläreunan painikkeesta. Tai tästä: Vaihda suomeksi.

Chapter 7.3: Traits and Type Hierarchies

About This Page

Questions Answered: How can I represent supertype–subtype relationships in my program? Concepts that have subconcepts? How can I make my program more generic and easier to extend?

Topics: Using traits for representing supertypes and subtypes. Abstract methods and variables. Static types vs. dynamic types. Type hierarchies.

What Will I Do? Read and program.

Rough Estimate of Workload:? Three or four hours.

Points Available: B100.

Related Modules: Traits (new). AuctionHouse2 (new) in an optional assignment.

Introduction: Two-Dimensional Shapes

Suppose we’re writing a program that deal with two-dimensional shapes such as circles and rectangles. Among other things, the program must be able to compute the areas of such shapes.

Note that we’re not dealing with images of circles or rectangles, for which we’ve used the Pic type. Instead, we seek to represent the mathematical concepts of circle and rectangle.

Here’s a first go at defining class Circle:

import scala.math.Pi

class Circle(val radius: Double):
  def area = Pi * this.radius * this.radius
  // Etc. Other Circle methods go here.

And class Rectangle:

class Rectangle(val sideLength: Double, val anotherSideLength: Double):
  def area = this.sideLength * this.anotherSideLength
  // Etc. Other Rectangle methods go here.

There’s nothing wrong with either class if we consider them individually. We could use each one independently in a program, but:

But #1

What if we want to compare different shapes by area?

We could add methods like so:

import scala.math.Pi

class Circle(val radius: Double):

  def area = Pi * this.radius * this.radius

  def isBiggerThan(another: Circle): Boolean = this.area > another.area

  def isBiggerThan(rectangle: Rectangle): Boolean = this.area > rectangle.area

end Circle

class Rectangle(val sideLength: Double, val anotherSideLength: Double):

  def area = this.sideLength * this.anotherSideLength

  def isBiggerThan(another: Rectangle): Boolean = this.area > another.area

  def isBiggerThan(circle: Circle): Boolean = this.area > circle.area

end Rectangle

But must we really write two separate methods? And replicate them in each class? Not very DRY. And what if there were more than two kinds of shapes?

And that’s not all.

But #2

What if we want a collection that stores references to different shape objects: circles, rectangles, and perhaps other shapes, too? Like this:

@main def shapeTest() =

  val shapes = Buffer[?????]()
  shapes += Circle(10)
  shapes += Rectangle(10, 100)
  shapes += Circle(5)

  var sumOfAreas = 0.0
  for current <- shapes do
    sumOfAreas += current.area
  println("The sum of the areas is: " + sumOfAreas)

end shapeTest

What should we write in place of ?????? What can we specify as the type of the elements in shapes?

On a related note: what is the type of current? It should be something like “any object that has an area method”, right?

Surely we don’t need to make separate lists for circles, rectangles, etc.? That wouldn’t be too practical.

We can shed some light on the problem by initializing the buffer’s elements as we create it:

@main def shapeTest() =

  val shapes = Buffer(Circle(10), Rectangle(10, 100), Circle(5))

  var sumOfAreas = 0.0
  for current <- shapes do
    sumOfAreas += current.area
  println("The sum of the areas is: " + sumOfAreas)

end shapeTest

The command is perfectly valid. Scala infers the types of expressions automatically where possible (Chapter 1.8). Since the elements include circles and a rectangle, the Scala compiler determines that this isn’t a “buffer of circles” or a “buffer of rectangles” but a “buffer of miscellaneous objects”. (The name of the inferred type is Buffer[AnyRef]. We’ll discuss the meaning of AnyRef further in Chapter 7.5.)

Since the buffer contains miscellaenous objects, current may refer to any such object. Which is why the attempt to call current.area now gives a compile time error to the effect that “The area method does not exist on any old object.”

It’s true that the method doesn’t exist on all objects. It’s great that the compiler questions our method call current.area. If we have a buffer of truly miscellaneous objects, we indeed should not be able call area on the buffer’s contents.

On the other hand, we happen to know that the objects that we put in this buffer do have something in common: the area method. It would be both natural and convenient if our shapeTest program worked.

What to do?

Subordinate and Superordinate Concepts

This is a circle. →

← This is also a shape.

We humans think of circles and rectangles as shapes. Shapes, in general, have an area. To us, it’s natural that a thing can be an instance of a more specific concept (such as circle) as well as its superordinate concept (such as shape). We can think of our program in these terms:

• “This program computes the total area of some shapes.”

• “All shapes have an area method.”

• “isBiggerThan expects any shape object as a parameter.”

This diagram illustrates the relationships:

An “is-a relationship” links the subordinate concepts to the more general one: every circle is a shape, for example.

We can also express this notion as code, as you’ll see below.

Defining a Superordinate Concept as a Trait

Let’s represent the concept of shape as a data type:

trait Shape:

  def isBiggerThan(another: Shape) = this.area > another.area

  def area: Double    

end Shape

We define a trait (piirreluokka) named Shape. Its purpose is to provide a generic definition for shapes: “In this program, in order for an object to qualify as a shape, it must possess the following methods — no matter what other properties it has or doesn’t have.”

We use the keyword trait rather than class but, that aside, this is pretty much like a regular class definition.

We define: all shapes have an isBiggerThan method that compares the areas of two shapes.

The parameter has the type Shape, meaning that we can pass in exactly the sort of object that the trait describes. This illustrates that we can use a trait as a data type just like we’ve used regular classes.

We define: all shapes have an area method for computing the size of the shape. But: we define only the method’s name, its parameters (none, in this case), and its return type (Double).

What we don’t define is an actual implementation for computing the area. Our method has no body! Such a method is known as an abstract method (abstrakti metodi).

This end marker, too, is optional. Since there are blank lines within this trait’s definition, we choose to write it here. (More about end markers in the style guide.)

Unlike the regular classes that we’ve written so far, a trait can contain abstract, unimplemented methods. The Shape trait says any shape’s area can be computed with a parameterless area method that produces a Double. How that Double is produced must be defined separately for different shapes.

Defining a subtype

We have now defined the generic concept of Shape but haven’t yet stated that circles and rectangles are shapes. Here’s how:

import scala.math.Pi

class Circle(val radius: Double) extends Shape:
  def area = Pi * this.radius * this.radius

class Rectangle(val sideLength: Double, val anotherSideLength: Double) extends Shape:
  def area = this.sideLength * this.anotherSideLength

The keyword extends marks Circle as a subtype of Shape.

You can read the definition like this: “The Circle class extends the type defined by the Shape trait.” Or: “The Circle class inherits the Shape trait.” In any case, the idea is that all objects of type Circle aren’t only Circles but also have the type Shape and all the properties defined in trait Shape.

A class can implement the abstract methods of a trait. For instance, here we define that a circle is a shape whose area comes from the formula π * r², and a rectangle is a shape whose area is the product of its two sides.

Note: extends Shape implies that circle and rectangle objects now also have an isBiggerThan method even though we didn’t write that method in the two classes.

A trait as a type for objects

Given the above, we now know that:

• Like regular classes, traits define data types.

• You can use the name of a trait to annotate a type onto a variable, just like you can use a class name.

• It’s possible to create objects that are of type Shape.

Does that mean you can write Shape() to create a new Shape object? If you do, what do you get?

Let’s try it:

Shape()-- Error
...

No. There are no Shape objects that are “just shapes”, and you can’t create such an instance. Which is good, since we haven’t defined an implementation of area for such hypothetical objects.

We must instantiate a trait indirectly by creating instances of classes that extend the trait, as illustrated below. Let’s start with a circle:

val myCircle = Circle(1)myCircle: o1.shapes.Circle = o1.shapes.Circle@1a1a02e

Next, we’ll try out a previously unfamiliar method named isInstanceOf, which is available on all Scala objects. It tells us whether an object is of a given type.

myCircle.isInstanceOf[Circle]res0: Boolean = true

Unlike most of the methods that we’ve used, isInstanceOf takes a type parameter, which goes in square brackets.

We ask the object that myCircle refers to whether it is of type Circle. It is.

Now let’s see if the same object is a Shape:

myCircle.isInstanceOf[Shape]res1: Boolean = true

True again. Our object has multiple types at once, as we wanted.

Of course, our object does not have all possible types. It’s not a Rectangle, for example.

myCircle.isInstanceOf[Rectangle]-- Warning:
  |myCircle.isInstanceOf[Rectangle]
  |^^^^^^^^
  |this will always yield false since type o1.shapes.Circle and class Rectangle are unrelated
res2: Boolean = false

A trait as a type for collection elements

Vector(Circle(1), Circle(2))res3: Vector[o1.shapes.Circle] = Vector(o1.shapes.Circle@e17571, o1.shapes.Circle@1e56bea)
Vector(Circle(1), Rectangle(2, 3))res4: Vector[o1.shapes.Shape] = Vector(o1.shapes.Circle@876228, o1.shapes.Rectangle@3d619a)

When the collection contains only circles, Scala infers the type as Circle.

When the collection also contains one or more rectangles, Scala finds the shared supertype, namely Shape.

The Introductory Problems, Solved

The problems we faced at the beginning of the chapter simply vanish with the introduction of the Shape trait.

isBiggerThan for all shapes

At the top of this chapter, we wrote multiple isBiggerThan methods on Circle and Rectangle. We don’t need them anymore. Our Shape trait defines a generic isBiggerThan method (replicated below) that works for comparing the areas of circles and rectangles — and any other specific shapes we might wish to add later! The method doesn’t care if the two shapes are instances of the same class or not, as long as they are Shapes of some kind.

trait Shape:

  def isBiggerThan(another: Shape) = this.area > another.area

  def area: Double

end Shape

In isBiggerThan, the two invocations of area are valid, because all Shapes have the area method. Despite being abstract, the method guarantees that no matter which specific sort of objects this and another happen to refer to, they definitely have some sort of implementation for area.

Implementation required!

To make it possible to instantiate Circle and Rectangle, we must implement the area method as stipulated in the Shape trait.

If we had left out area from Circle or Rectangle, we would have received a compile-time error about the missing method. That is, the Scala toolkit ensures that any concrete object that we create has actual implementations for any abstract methods that the object inherits from its supertypes. This means that we can count on objects to have implementations for the methods that we call on them.

shapeTest also works now

Now that we have the Shape trait, our original test program works unchanged:

@main def shapeTest() =

  val shapes = Buffer(Circle(10), Rectangle(10, 100), Circle(5))

  var sumOfAreas = 0.0
  for current <- shapes do
    sumOfAreas += current.area
  println("The sum of the areas is: " + sumOfAreas)

end shapeTest

The inferred type of the buffer’s elements is Shape.

Had we felt like it, we could have written the type explicitly as Buffer[Shape].

Calling current.area is now legal because current is of type Shape and the trait guarantees that all Shape objects have an implementation for area.

Extending a Trait with a Singleton

To have singleton object inherit a trait, you can write extends just like you would on a class. Such a singleton object represents a special case of the general concept captured in the trait. If the trait has any abstract methods, you’ll need to implement them in the singleton object.

object SingularShape extends Shape:
  def area = 51                      // implements the abstract method
  val description = "non-Euclidian"  // an additional variable on this object alone

In fact, you’ve already done that. Scala’s App is not a regular class but a trait that represents the concept of a runnable application. When you write extends App on a singleton object, your object inherits the App trait. In other words: you make that singleton object a special case of the App supertype.

Questions about Variables and Types

Question 1

Which of the code snippets below make sense to you? Which of them are valid? Which of them are invalid and why?

Assume that trait Shape is defined as above, as are its subtypes Circle and Rectangle.

The answers are relatively commonsensical. If you don’t know, take a guess. The text below discusses the phenomena highlighted by the questions.

var test = Rectangle(10, 10)
println(test.area)
test = Rectangle(10, 20)
println(test.area)

The program is valid. There’s nothing unusual about it.

The program is invalid.

Question 2

var test = Shape(10, 20)
println(test.area)

The program is valid.

The program is invalid.

Question 3

var test = Rectangle(5, 10)
println(test.area)
test = Circle(10)
println(test.area)

The program is valid.

The program is invalid.

Question 4

var test: Shape = Circle(10)
println(test.area)
test = Rectangle(10, 20)
println(test.area)

The program is valid.

The program is invalid.

Static Types vs. Dynamic Types

Let’s recap a couple of terms from Chapter 1.2:

• We use the word static for the aspect of a program that exists even when the program is not running. That is, the word refers to things that are present in the program text or directly deducible from it.

• We use the word dynamic for the aspect that a program gains by being run: the process of program execution and things that happen during that process. All the dynamic properties of a program aren’t present in the program code alone; user input can impact on what happens during a program run, for example.

In Chapter 1.3, we noted that expressions have values and those values have types. And in Chapter 1.4, we saw that variables have types. That chapter also told us that when you assign a value to a variable, the value’s type must be compatible with the variable’s type. Until now, “must be compatible” has effectively meant “must be the same as”. However, now that we’ve introduced traits, it’s time to consider compatibility a bit more carefully.

In statically typed languages such as Scala, we can distinguish between static types and dynamic types, as discussed below.

Static types

A static type (staattinen tyyppi) is a type that can be determined by examining program code, without running the program, and that is unaffected by runtime factors such as user inputs. Here are a few examples:

• We annotate each method parameter with its static type.

• Given the code val text = "llama", it’s clear that the variable text has a static type of String.

• The expression 1 + 1 can be inferred to have the static type Int given that each of its subexpressions is a literal with the static type Int.

Variables and expressions have static types. That is, it is those parts of program code, not their values, that have static types!

Static types dictate which operations and method calls are valid and which ones aren’t. A method call like myObject.someMethod() produces a compile-time error unless the myObject has a static type that defines a parameterless someMethod.

Dynamic types

The values of variables and expressions have dynamic types (dynaaminen tyyppi). These types are affected by what happens during a program run.

In many cases, a value’s dynamic type will exactly match the static type of the corresponding variable or expression. For instance, the expression 1 + 1 evaluates to the integer value two, whose dynamic type is Int, which is the same as the expression’s static type.

The following program demonstrates the distinction between static and dynamic types:

var test: Shape = Rectangle(10, 20)
println(test.area)

test = Circle(10)
println(test.area)

val selected = readLine("Would you like a circle? Say 'hip' if you do, or you'll get a square. ")

if selected == "hip" then
  test = Circle(readLine("Radius: ").toInt)
else
  val side = readLine("Side length: ").toInt
  test = Rectangle(side, side)

println(test.area)

We give test the type Shape so that it can store a reference to any object whose class inherits Shape.

Each use of the name test as an expression therefore has the static type Shape. That means it’s legal to call test.area, since the area method is defined on Shape.

However, the value of the expression test has a dynamic type that isn’t Shape. As this program is run, the variable first refers to a Rectangle object, then a Circle. On the last line, the value of test has a dynamic type that depends on which string the user has entered.

Each time we call area, one of the different implementations for that method is activated. Which one, depends on the dynamic type of the value that we call the method on; the names of methods are dynamically bound to implementations. In other words: what happens as a reaction to a message sent to an object depends on the specific type of the object that receives the message.

As you see, a value’s dynamic type doesn’t need to be identical with the static type of the corresponding variable; it just needs to be type compatible (tyyppiyhteensopiva). You may store a reference to a Circle object in a variable of type Circle or a variable of type Shape, but not in a variable of type String or Obstacle.

Types in the REPL

Here are a few more examples in the REPL. Observe how the REPL outputs the static types of the variables to the left of the equals sign, as well as the dynamic types on the right as part of the objects’ descriptions.

var test1 = Rectangle(5, 10)test1: o1.shapes.Rectangle = o1.shapes.Rectangle@38c8ed

The static type of the variable test1 is inferred from the type of the expression whose value is initially assigned to the variable. Since that static type is Rectangle, we can’t make the variable refer to a circle object. An attempt to do so provokes a clearly worded error message:

test1 = Circle(10)-- Error:
  |test1 = Circle(10)
  |        ^^^^^^^^^^
  |        Found:    o1.shapes.Circle
  |        Required: o1.shapes.Rectangle

However, if we specifically give the variable the Shape type, that static type is “wider” than the value’s dynamic type:

var test2: Shape = Rectangle(5, 10)test2: o1.shapes.Shape = o1.shapes.Rectangle@bdee1c

This variable can also hold a reference to a circle:

test2 = Circle(10)test2: o1.shapes.Shape = o1.shapes.Circle@1071884

Questions about traits and types

Take another look at shapeTest:

@main def shapeTest() =

  val shapes = Buffer(Circle(10), Rectangle(10, 100), Circle(5))

  var sumOfAreas = 0.0
  for current <- shapes do
    sumOfAreas += current.area
  println("The sum of the areas is: " + sumOfAreas)

end shapeTest

Question 1

What is the static type of the variable current?

Rectangle

Circle

Shape

Circle some of the time, Rectangle at other times

both Circle and Rectangle

Question 2

In the area below, please list the dynamic type of each value stored in current as the program runs. Enter each type on a separate line, in order. (Just the class names, please; leave out the package name.)

Question 3

In this question and the ones below it each give you a piece of code. Assess whether that code is valid or if it produces a compile-time error.

var test = Circle(10)
println(test.radius)

The program is valid. There is nothing unusual about it.

The program is invalid.

Question 4

var test: Shape = Rectangle(10, 20)
println(test.radius)

The program is valid.

The program is invalid.

Question 5

var test: Shape = Rectangle(10, 20)
println(test.area)
test = Circle(10)
println(test.radius)

The program is valid.

The program is invalid.

Question 6

var test: Shape = Circle(10)
println(test.radius)

The program is valid.

The program is invalid.

What’s the point of that restriction?

Why does it make sense that the static type of an expression decides which operations are valid? Why should it be illegal to use radius as shown in the last example above?

This section should give you an idea of the answers. If you feel you have a good idea already, it’s fine to skip ahead.

Restricting operations by static type is especially relevant in methods that use Shape or another supertype in their parameter. An example is isBiggerThan in trait Shape:

trait Shape:

  def isBiggerThan(another: Shape) = this.area > another.area

  def area: Double

end Shape

The variable another refers to some shape object; the variable’s static type is Shape. The method call another.area is valid only because area is a method on this static type.

In contrast, we couldn’t rewrite this method to compare shapes by their radiuses. The expression another.radius would be invalid since not all the objects that can be passed as parameters to isBiggerThan have a radius. If another.radius were accepted by the compiler, and we then called the method and passed in a rectangle, the method would fail and crash our program at runtime.

The same goes for this, whose static type is Shape because the code is within the Shape trait. this.radius is just as invalid as another.radius.

In more general terms: when you use a supertype in a method parameter, that method can use the parameter only for the things that are shared by all instances of the supertype. This ensures that the method works for any and all instances of all subtypes.

Static types help the programmer’s tools (the compiler, in particular) locate errors and to notify you before you run your program. If the tools didn’t enforce method calls in this way, we’d suffer a great loss in type safety. (Cf. what was said about static and dynamic typing at the end of Chapter 1.8.)

Working around that restriction

But what if you do have a reference to a Circle object stored in a Shape variable and really want to access the object’s radius property? Or what if you want to make a decision during a program run based on whether a Shape variable happens to refer to a circle or some other shape?

In such cases, you can turn to match (Chapter 4.3) for assistance. match uses the dynamic type of a value as it selects among alternatives:

var someShape: Shape = Circle(10)someShape: Shape = Circle@1de2de2
someShape match
  case someCircle: Circle =>
    println("It's a circle and its radius is " + someCircle.radius)
  case _ =>
    println("It's not a circle!")It's a circle and its radius is 10.0

In case someShape happens to hold a reference to a Circle, that reference gets stored in the variable someCircle. The static type of someCircle is Circle.

You can read case _ as “in all other cases” (Chapter 4.4).

An alternative method that is generally worse

Another option is to use the asInstanceOf method, which all Scala objects have. In the example below, notice the type parameter and the static type of the return value.

someShape.asInstanceOf[Circle]res5: Circle = Circle@1de2de2
someShape.radius-- Error: ... value radius is not a member of o1.shapes.Shape

Be warned! This would have caused a runtime error if someShape hadn’t happened to refer to a circle. The compiler can’t check the dynamic type for you. By electing to use asInstanceOf, you the programmer bypass the strong typing of the language and weaken your program’s type safety. It’s then entirely up to you to ensure that the object’s dynamic type really matches what you wrote in square brackets after asInstanceOf. Use this method carefully if at all — and never in O1.

asInstanceOf corresponds to what is known in many other programming languages as a type cast or simply a cast (tyyppimuunnos).

Programming Assignment: Using and Editing a Trait

Part 1 of 2: a new kind of shape

Write a new subtype for Shape: class RightTriangle, which represents triangles that have a 90-degree angle. Right triangles should have all the general properties that shapes have as well as an additional method hypotenuse. The class should work as shown below.

val triangle = RightTriangle(3.0, 4.0)triangle: o1.shapes.RightTriangle = o1.shapes.RightTriangle@18bcb2d
triangle.hypotenuseres6: Double = 5.0
triangle.areares7: Double = 6.0
Circle(3).isBiggerThan(triangle)res8: Boolean = true
triangle.isBiggerThan(Rectangle(7, 5))res9: Boolean = false

In this assignment, you must not define isBiggerThan within the RightTriangle class, nor is there any reason to do so. Instead, RightTriangle must inherit the Shape trait. Triangles, like circles and rectangles, will then have isBiggerThan by virtue of being Shapes.

Part 2 of 2: perimeters of shapes

1. Add an abstract method perimeter in trait Shape in the Traits module. This parameterless method should return the shape’s perimeter (the total length of the shape’s border) as a Double.

2. After adding this method in Shape.scala, notice how IntelliJ disapproves: the definitions of the three subtypes are no longer valid because they fail to implement perimeter.

3. Implement perimeter in your new RightTriangle class and in the given classes Circle and Rectangle. (The module also comes with a class named Square, which we’ll discuss later.) Use cases:

triangle.perimeterres10: Double = 12.0
Circle(5).perimeterres11: Double = 31.41592653589793
Rectangle(2, 5).perimeterres12: Double = 14.0

A+ presents the exercise submission form here.

Optional add-ons

You can try adding a triangle or two to the buffer in shapeTest. This should be easy, assuming you defined RightTriangle appropriately.

You may also wish to write toString methods in RightTriangle and the other shape classes so that they are easier to work with in the REPL. Or you could write a generic toString for all shapes in trait Shape, if you prefer.

Thoughts about traits

Traits are handy. What’s more, defining supertypes can greatly improve program quality. For example:

• With traits, you can create program components that are more generic. You can, for instance, define a method such as isBiggerThan, which works equally well on shapes of different types.

• Traits reduce redundancy, which makes your code more maintainable. They can also make your programs easier to extend by adding new subtypes. For instance, when you added triangles to our program, you just wrote extends Shape and implemented area. That was enough to give triangle objects isBetterThan, too, and to make triangles usable in any part of the program that operates on Shapes.

Practice on Traits and Abstract Methods

Question 1

Consider the example code below.

trait T1:
  def m1 = 1
  def m2: Int

class A(val x: Int, val y: Int) extends T1:
  def m2 = this.x + 1
  def m3 = this.y + 1

class B(val x: Double, val y: Int) extends T1:
  def m2 = this.x.toInt + 1
  def m3 = this.y + 2

Which of the following claims are correct? Select all that apply.

Assume that T1, A, and B have been defined as above and that there may also be other classes in the program that extend trait T1.

The trait T1 defines one abstract method and one regular (non-abstract) method.

It is possible to call m1 on some, but not all, objects of type T1 that can exist. (Read “objects of type T1 that can exist” as “objects that can be instantiated from the given classes or some other class X that could exist and extend T1”.)

It is possible to call m1 on all objects of type T1 that can exist.

It is possible to call m2 on some, but not all, objects of type T1 that can exist.

It is possible to call m2 on all objects of type T1 that can exist.

It is possible to call m3 on some, but not all, objects of type T1 that can exist.

It is possible to call m3 on all objects of type T1 that can exist.

It is possible to call m1 on some, but not all, objects of type A that can exist.

It is possible to call m1 on all objects of type A that can exist.

Multiple Supertypes

Supertypes at different levels

A trait may inherit another. Here is an example:

trait PersonAtAalto:
  // Here, we can add methods and/or instance variables that are common to
  // all people at Aalto, whether they are employees, students, or visitors.
end PersonAtAalto

trait Employee extends PersonAtAalto:
  // Here we can add methods and/or instance variables for Aalto employees.
  // All employees have these properties in addition to the generic ones
  // they get from the PersonAtAalto trait.
end Employee

Now we can define class TeachingAssistant that inherits Employee, thus turning assistants into both employees and persons:

class TeachingAssistant extends Employee:

  // Assistant objects have all the methods and instance variables defined
  // in the Employee trait as well as those defined in PersonAtAalto.

  // Here, we can add variables and methods that are specific to teaching
  // assistants.

end TeachingAssistant

A “family tree” of data types is called a type hierarchy (tyyppihierarkia).

A type hierarchy may have many branches and levels.

Multiple immediate supertypes

In our example, the TeachingAssistant class had an immediate supertype in Employee and an additional indirect supertype in PersonAtAalto. You can also give a class (or trait) multiple direct supertypes, as shown below.

Suppose we have an additional trait, Student. We wish to model the fact that teaching assistants are students in addition to being employees. This is easy:

class TeachingAssistant extends Employee, Student:
  // Now assistants are of all the following types:
  // TeachingAssistant, Student, PersonAtAalto, Employee.
  // (They gain the properties of PersonAtAalto just once
  // even though there are two “paths” up to that trait.)
end TeachingAssistant

If there are still more traits you wish to inherit from, just list them:

class X extends MyTrait1, MyTrait2, MyTrait3, MyTrait4

The listed traits don’t need to have a shared supertype (even though in our example, PersonAtAalto was one for Employee and Student). A class may inherit multiple traits that are otherwise quite unrelated to each other.

The word with also works where we wrote the commas. Use whichever style you prefer, but it’s good to be aware of both:

class TeachingAssistant extends Employee with Student

class X extends MyTrait1 with MyTrait2 with MyTrait3 with MyTrait4

Question 1

Here is the code from the previous exercise:

trait T1:
  def m1 = 1
  def m2: Int

class A(val x: Int, val y: Int) extends T1:
  def m2 = this.x + 1
  def m3 = this.y + 1

class B(val x: Double, val y: Int) extends T1:
  def m2 = this.x.toInt + 1
  def m3 = this.y + 2

Let’s add a couple of definitions:

trait T2:
  def m4 = 4

class C extends T1, T2:
  def m2 = 2
  def m3 = 3.0

Which of these claims are correct? Select zero, one, or two items as appropriate.

The definition of m3 in class C is invalid: we can’t have it return a Double, since we’ve already stated elsewhere that the return type should be Int.

It is possible to call m1, m2, m3, and m4 on all objects of type C that can be created.

Overriding Supertype Methods

Since Week 2, we have used override to replace default method implementations with class- or object-specific ones. In particular, we have used this keyword in:

• toString methods: the methods that we’ve written have overridden the default implementation (which produces descriptions such as o1.shapes.Square@ecfb83).

• the event handlers on Views (such as onClick; Chapter 3.1): the default implementations in class View react to events by doing nothing at all but you can override them with whichever behavior you wish your application to have.

You can also override other methods in type hierarchies. As an experiment, let’s write a few mini-classes.

trait TraitX:
  def greeting = "Hello from TraitX"

class Class1 extends TraitX

class Class2 extends TraitX:
  override def greeting = "Hello from Class2"

Now let’s use our classes in the REPL:

Class1().greetingres13: String = Hello from TraitX
Class2().greetingres14: String = Hello from Class2

Class1 gets its greeting method from TraitX.

Class2 overrides the trait’s method with an implementation of its own.

In Scala, you must always explicitly use the override keyword whenever you wish to override a method.

Why require an explicit override? Because it’s salty.

By writing override in your program, you acknowledge that you are deliberately superseding a method implementation defined on a supertype. If the keyword was optional, you might easily give your method a name that is already used in a supertype. Such a thing could happen quite accidentally and unknowingly, possibly spawning exotic bugs.

Like static typing, this requirement is a language feature that reduces the chance of human error. Such a language feature, which makes it harder to write bad code, is sometimes called “syntactic salt” (cf. the more common term syntactic sugar).

As an added benefit, the keyword makes overriding explicit to the program’s readers.

Let’s add another trait and a couple of classes to our type hierarchy:

trait TraitY extends TraitX:
  override def greeting = "Hello from TraitY"

class Class3 extends TraitY

class Class4 extends TraitY:
  override def greeting = "Hello from Class4"

Our second trait thus inherits the first, and the new classes inherit the second trait.

Now to try them out:

Class3().greetingres15: String = Hello from TraitY
Class4().greetingres16: String = Hello from Class4

Class3 doesn’t define its own implementation for the greeting method. It inherits the method from its immediate supertype TraitY (which overrides the method from TraitX further up in the hierarchy).

Class4 supplies an overriding implementation, which supersedes both the one in TraitY and the one in TraitX.

Let’s explore further:

var myObject: TraitX = Class1()myObject: TraitX = Class1@6d293b41
myObject.greetingres17: String = Hello from TraitX
myObject = Class4()myObject: TraitX = Class4@dc6c5ca
myObject.greetingres18: String = Hello from Class4

The variable’s static type is TraitX. Its value has the dynamic type Class4.

We can call greeting on any expression with the static type TraitX (or one of TraitX’s subtypes); that is, we can call it on any object that is guaranteed to have the method. On the other hand, what happens when we do so depends on the dynamic type of the object that receives the message. Here, we execute the greeting implementation defined on Class4 objects, even though the variable is of type TraitX.

The super keyword

One more class:

class Class5 extends TraitY:
  override def greeting = super.greeting + " and from Class5 too"

You can use the super keyword to refer to an implementation defined in a supertype. Here, we call the supertype’s version of greeting. As a consequence, the greeting method of a Class5 object first obtains whichever string the greeting method on its supertype TraitY returns, and then adds some more text that is specific to Class5. See below for an example.

Class5().greetingres19: String = Hello from TraitY and from Class5 too

Practice on super and override

For the following questions, suppose we have a few types defined as follows:

trait Supertrait:
  def number1: Int = 1
  def number2: Int
  def number3: Int = 3
  def number4: Int = 4

trait Subtrait extends Supertrait:
  override def number1 = 10
  def number2 = 20
  override def number4 = super.number4 + 40

class Test(val myNumber: Int) extends Subtrait:
  override def number1 = 100
  override def number2 = super.number2 + 200
  override def number3 = super.number3 + 300
  override def number4 = super.number4 + 400
  def number5 = this.myNumber + this.number1 + super.number1 + this.number4 + super.number4

Further suppose that we’ve created a Test object like this:

val myTest = Test(1000)

Each of the five questions below prompts you to enter the integer that a method call returns. Once again, the point is of course not the specific integers, but why the code produces them, so read the code carefully and figure out the answers.

Question 1

What is returned if you call myTest.number1?

Question 2

How about myTest.number2?

Question 3

How about myTest.number3?

Question 4

How about myTest.number4?

Question 5

How about myTest.number5?

Instance Variables in a Trait

A trait can define instance variables just like a class can.

trait Supertype:
  val magicNumber = 42
  val text: String// defined trait Supertype
class Subtype extends Supertype:
  val text = "value of 'text' for all Subtype instances"// defined class Subtype

Like a method, an instance variable on a trait can be abstract.

All instances of inheriting classes are guaranteed to have the trait’s variables:

val myObject: Supertype = Subtype()myObject: Supertype = Subtype@714aadf7
myObject.magicNumberres20: Int = 42
myObject.textres21: String = value of 'text' for all Subtype instances

Constructor Parameters on a Trait

Example: medical professionals

Let’s write a trait to represent healthcare professionals:

trait MedicalPro

On the right is a diagram of the type hierarchy that we’ll soon define.

As a first step, let’s focus on just one of MedicalPro’s subtypes: Paramedic. Paramedics work in emergency services; for each Paramedic object, we’ll record whether they are part of an ambulance crew (or stationed at a hospital).

class Paramedic(val inAmbulance: Boolean) extends MedicalPro

Suppose we also want to record, for all kinds of MedicalPro objects, an employer. We’d like the employer to be stored in a String variable and to receive a value from a constructor parameter when the object is created.

We can add such a constructor parameter, and a corresponding val, in a trait just like we’d write them in a regular class:

trait MedicalPro(val employer: String)

MedicalPro objects don’t get created directly but through the trait’s subtype. So how should we pass a value to that constructor parameter? And how should we take employers into account in class Paramedic?

Let’s say we want to create Paramedic instances as illustrated below, by passing in first an employer and then a Boolean to be stored in inAmbulance.

val medic = Paramedic("City of Helsinki", true)medic: Paramedic = Paramedic@61c98b6c

Below is a class definition that works like that. For example’s sake, let’s assume that all paramedics work in the public sector and are employed by a city.

class Paramedic(city: String, val inAmbulance: Boolean) extends MedicalPro(city)

We added a constructor parameter. Note that this parameter is not marked with val; if it had been, an instance variable named city would also have been defined. What we want instead is to pass the value of the constructor parameter city onward to the MedicalPro trait, which will store it in the employer variable.

The constructor parameter inAmbulance and the corresponding instance variable we already had in our first version of Paramedic. Nothing new here.

The interesting part is this: to create an instance of a subtype, any initialization steps that the supertype demands must also be performed. It’s common to pass constructor parameters from a subtype to a supertype, as shown here. In this example, we state that whenever a Paramedic object is created, we initialize a MedicalPro by passing it the first of the two constructor parameters that Paramedic received. (See the animation below.)

The example continues

Now to deepen our type hierarchy. Let’s add a Doctor trait. For the purposes of this basic example, we’re not planning to record any information about Doctors apart from their employer, which is already covered by MedicalPro. So just this will do:

trait Doctor extends MedicalPro

Our simple hierarchy divides doctors in two groups: general practitioners and specialists. The Specialist trait indicates that a subfield of medicine should be recorded for every specialist doctor:

trait Specialist(val specialization: String) extends Doctor

We mean the GeneralPractitioner class to be used like this:

val gp = GeneralPractitioner("InstaCare Hospital")gp: GeneralPractitioner = GeneralPractitioner@4df03572

Here’s a first try at implementing it:

class GeneralPractitioner(employer: String) extends Doctor      // fails to work

The basic idea is just fine there: we’ve made GeneralPractitioner inherit Doctor, and Doctor already inherits MedicalPro. Something’s missing, though. We get a compile-time error that suggests what’s wrong:

class GeneralPractitioner(employer: String) extends Doctor-- Error:
  |class GeneralPractitioner(employer: String) extends Doctor
  |      ^
  |      parameterized trait MedicalPro is indirectly implemented,
  |      needs to be implemented directly so that arguments can be passed

In other words, we have a MedicalPro trait higher up in the hierarchy, and since that trait takes a constructor parameter, we need to supply one. The fix is to mention that supertype explicitly:

class GeneralPractitioner(employer: String) extends MedicalPro(employer), Doctor

The new GeneralPractitioner object received an employer string as a constructor parameter. We state that we pass precisely that string to the supertype MedicalPro.

Again, we didn’t write val in front of the constructor parameter. The instance variable named employer is already defined as part of MedicalPro. What we have here is just GeneralPractitioner’s constructor parameter, whose name we’re free to pick; employer is as good a choice as any.

We’re still missing Neurologist, which is supposed to represent doctors specialized in neural matters. We mean this class to work like this:

val doc = Neurologist("Chicago Grace Hospital")doc: Neurologist = Neurologist@4f13e602
doc.specializationres22: String = neurology

Let’s recap the traits we’ve already defined:

trait MedicalPro(val employer: String)

trait Doctor extends MedicalPro

trait Specialist(val specialization: String) extends Doctor

Given those definitions, we can implement Neurologist like this:

class Neurologist(employer: String) extends MedicalPro(employer), Specialist("neurology")

We pass the employer as a constructor parameter to MedicalPro, just like we did previously.

The Specialist trait, too, demands a string as a constructor parameter. We give it a specific text what we want each Neurologist object to have as a specialization.

The Doctor trait is also a supertype of Neurologist. We didn’t need to specifically mention it after extends, since Doctor is a supertype of Specialist and since no constructor parameters need to be passed to Doctor.

The code for this example hierarchy is available in the Traits module.

Assignment: Messages of Different Kinds

In o1.messages of the Traits module, you’ll find a handful of toy classes that represent messages sent by users on social media. A few different kinds of messages are represented:

• A DirectMessage is a message sent to a specific recipient.

• A Post is a message that hasn’t been directed at a specific person.

• A Comment is a message that is response to an original Post.

• Message is a supertype for all these different kinds of messages; it’s a trait. What all Messages have in common is an instance variable named content, which holds the message text as a String.

• And then there’s another trait, Reply. It represents messages that are responses to something. As shown in the diagram to the right, Comment is meant to be a subtype of Reply, although that bit hasn’t actually been written into the given code yet.

Your task is to study the given code and made the following modifications to it:

1. Have Comment inherit Reply, too, by filling in Comment’s extends clause. Remember that Reply takes a constructor parameter; you can give it the Post object that the comment replies to (which a Comment receives via its original parameter).

2. Make all Message objects hold an additional piece of information: whether the message is public or not. Do this by declaring a constructor parameter and an instance variable on Message’s first line: val isPublic: Boolean. Then edit classes DirectMessage, Post, and Comment to be compatible with the revised Message trait, as described below.

3. Direct messages aren’t public: from DirectMessage, pass in the literal false as the second constructor parameter to Message.

4. A Post may or may not be public. Add a second constructor parameter to the Post class; it should be a Boolean. Pass the value of that parameter onward to the Message trait.

   • You can name the parameter isPublic or something else. Note that you shouldn’t mark it as a val, since the intention is not to give Posts a new instance variable.

5. A Comment can also be either public nor non-public. Give it a (third) constructor parameter as you did for Post.

In the same file, you’ll also find a little test program. Once you’re done editing the classes, you can uncomment the test program and try it out.

A+ presents the exercise submission form here.

Practice on Type Hierarchies and Overriding

The frivolous program below features a combination of many of the techniques that we’ve just discussed. You can use it for checking your understanding. If you can tell — in detail! — what this program does, then you will have grasped some of the main principles of traits and type hierarchies. This practice task is optional.

A story about driving

Read the code below. Painstakingly consider which exact lines of text it outputs and in which order. Ideally, you should write down what you think the program outputs.

@main def driveAbout() =
  val car = Car()
  car.receivePassenger(Schoolkid())
  car.receivePassenger(ChemicalEngineer("C. Chemist"))
  car.receivePassenger(MechanicalEngineer("M. Machine"))
  car.receivePassenger(ElectricalEngineer("E. Electra"))
  car.receivePassenger(ComputerScientist("C.S. Student"))
  car.start()

class Car:
  private val passengers = Buffer[Passenger]()

  def receivePassenger(passenger: Passenger) =
    passenger.sitDown()
    this.passengers += passenger

  def start() =
    println("(The car won't start.)")
    for passenger <- this.passengers do
      passenger.remark()
end Car

trait Passenger(val name: String):
  def sitDown() =
    println(this.name + " finds a seat.")

  def speak(sentence: String) =
    println(this.name + ": " + sentence)

  def diagnosis: String

  def remark() =
    this.speak(this.diagnosis)
end Passenger

trait Student extends Passenger:
  def diagnosis = "No clue what's wrong."

class Schoolkid extends Passenger("Anonymous pupil"), Student

trait TechStudent extends Student:
  override def remark() =
    super.remark()
    this.speak("Clear as day.")

class ChemicalEngineer(name: String) extends TechStudent, Passenger(name):
  override def diagnosis = "It's the wrong octane. Next time, I'll do the refueling."

class MechanicalEngineer(name: String) extends TechStudent, Passenger(name):
  override def diagnosis = "Nothing wrong with the gas. It must be the pistons."
  override def speak(sentence: String) =
    super.speak(sentence.replace(".", "!"))

class ElectricalEngineer(name: String) extends TechStudent, Passenger(name):
  override def sitDown() =
    println(this.name + " claims a front seat.")
  override def diagnosis = "Hogwash. The spark plugs are faulty."

class ComputerScientist(name: String) extends TechStudent, Passenger(name):
  override def remark() =
    this.speak(super.diagnosis)
    this.speak(this.diagnosis)
  override def diagnosis = "Let's all get out of the car, close the doors, reopen, and try again."

Did you read the program carefully? Did you write down the output you expect?

Now open the Traits module and run o1.cruising.Cruising (which is the above program). Was the output precisely what you expected? If not, find out why.

You may wish to use the debugger as an aid.

Question 1

I now understand why the program does what it does.

!(I now understand why the program does what it does.)

Assignment: Legal Entities

Task description

Study the documentation of o1.legal in module Traits. The documentation lays out a number of classes and traits that represent court cases and the legal entities involved in such cases (also known as “legal persons”).

Implement the classes in the given files. (See the comments in the files for where to place each class.)

There are quite a few classes, but they are simple. This assignment is primarily concerned with the relationships between these classes, which are illustrated in the diagram below.

This assignment is submitted in two parts:

• Part 1: Implement CourtCase, Entity, and all of Entity’s subtypes except for the JuridicalPerson branch of the type hierarchy.

• Part 2: Implement JuridicalPerson and its subtypes.

Part 1 of 2: Recommended steps and other hints

1. Browse the documentation for CourtCase, Entity, NaturalPerson, and JuridicalPerson to get an overall sense of those four types.

2. Write CourtCase. Note that each court case is associated with two variables whose type is defined by the Entity trait. The referred objects are legal entities of some kind, but CourtCase doesn’t care which.

3. Write trait Entity in a file of its own.

4. Write NaturalPerson in a file of the same name.

   • As stated in the docs, you’ll need to extend another trait.

   • The Scaladocs tell you which methods of each class come from a supertype and which ones are new to the specific type described on the page. Near the top of each Scaladoc page, there is a section where you can filter what’s shown on the page. Open that section fully with a click, and you’ll see an area labeled Inherited, whose buttons adjust which methods are shown. Try the buttons.

5. Write FullCapacityPerson.

   • Especially since we’re dealing with simple, closely related types, it makes sense to define the subtypes of NaturalPerson in the same file with their supertype.

   • Note the class header at the top of the doc page: this class should be marked as extending both Entity and NaturalPerson. Just the latter would enough otherwise, but you need to pass a constructor parameter to Entity, too. (This is similar to what we had in the MedicalPro and Message examples above.)

   • The supertype already defines an instance variable for storing the entity’s name, so you don’t need a val for that here. (This, too, is similar to the earlier examples.)

6. Open Restriction.scala, which will help you represent people whose capacity to act on their own behalf in court is reduced for one reason or another. The Restriction trait is there already, as is a singleton object Illness that extends it. Add Underage, a similar singleton.

7. Write ReducedCapacityPerson.

   • You’ll again need to pass a constructor parameter to two separate supertypes.

   • If you have implemented the earlier methods correctly, this should work as an implementation for the kind method:

     override def kind = super.kind + " with " + this.restriction
     

A+ presents the exercise submission form here.

Part 2 of 2: Recommended steps and other hints

1. Write JuridicalPerson. Just one line of code will do (since no additional methods are needed).

2. Implement HumanOrganization and GeographicalFeature.

   • If you have a parameterless, abstract def in a supertype, you may implement it with a variable in a subtype. Define a contact variable in HumanOrganization and a kind variable in GeographicalFeature.

   More info about implementing a def with a variable

   It is indeed valid to implement an abstract, parameterless method with a variable, as suggested above for contact, for example. The important thing is that an expression such as someOrganization.contact must have a NaturalPerson as a value, one way or another. For a user of the HumanOrganization class, it’s generally irrelevant whether they are dealing with a val or an effect-free, parameterless method that efficiently returns the same value every time. (Further reading: the Wikipedia article on the uniform access principle and an educational slide deck by Philip Schwartz.)

3. You don’t have to bother writing Nation, Municipality, and Corporation; there is nothing novel about these classes. You can just uncomment the given implementations. If you have correctly defined the supertypes, these subtypes should work as given.

4. Implement Group.

   • In this program, groups don’t have distinct names. Read the documentation carefully, and pass the appropriate string literal as a constructor parameter to the Entity trait.

A+ presents the exercise submission form here.

Reimplementing Auctions as a Type Hierarchy

The following programming assignment revisits our earlier auction-themed programs. The assignment itself is optional, but I highly recommend that you at least read what it’s about.

In Chapter 5.1, you presumably wrote FixedPriceSale and may have also written DutchAuction and EnglishAuction. These classes represent items put up for sale in a variety of ways. Then, in Chapter 5.5, we designed AuctionHouse to represent auction houses where all the items are sold in the traditional “English” style.

You can use your own earlier solutions as a basis for the upcoming assignment. If you didn’t do some or all of them, feel free to use the example solutions (FixedPriceSale, DutchAuction, EnglishAuction).

A new class hierarchy

Here’s how the existing classes relate to each other:

In other words: an AuctionHouse contains EnglishAuctions. The classes FixedPriceSale and DutchAuction are unconnected to the others.

In this assignment, you’ll refactor the classes. The purpose of refactoring is to improve program quality: you’ll modify FixedPriceSale-, EnglishAuction, and DutchAuction so that it’s easier to use them all in combination. At the same time, you’ll eliminate a great deal of redundant code. In this exercise, the main tool for refactoring will be traits.

The goal is a hierarchy of classes that looks like this:

At the heart of our plan is the trait ItemForSale, which will serve as a generic supertype for items being sold in all sorts of ways. We’ll be able to use this supertype to write a more generic AuctionHouse class. We’ll also introduce an InstantPurchase trait to capture what fixed-price items and Dutch-style auctions have in common.

Implement the refactoring

Implement ItemForSale, EnglishAuction, InstantPurchase, FixedPriceSale, DutchAuction, and AuctionHouse so that they match the documentation provided in module AuctionHouse2.

Instructions and hints:

• We recommend that you implement the classes in the order listed above.

• As you read the Scaladocs, be sure to note which methods are abstract. Also note which methods each class inherits from its supertype(s).

• Recap: if a supertype already defines a concrete instance variable, don’t repeat the val in subtypes. For instance, the description variable is defined in the supertype ItemForSale, so don’t redefine it as a val in the subtypes. The subtypes do need a description as a constructor parameter, though.

• You can use the given test app to try some of the key methods. You’ll observe that the app object o1.auctionhouse.gui.TestApp generates a bunch of error messages to begin with, but they’ll vanish once you make the requested changes.

  

• In the AuctionHouse class, you’ll need to replace EnglishAuction with a more general type, but that’s the only change needed there.

A+ presents the exercise submission form here.

Once you finish the assignment, pause for a moment to admire the results: the type hierarchy turned the disconnected and redundant classes into a beautiful conceptual model. The definition of each concept includes only what is necessary to distinguish it from related concepts.

More Optional Practice

Tools in package o1 (and FlappyBug, once more)

The course library o1 contains a HasVelocity trait, which is a generic type for objects that have a location and a velocity in two-dimensional space. We have already modeled some such objects in our programs, albeit without using this trait. Let’s explore how the trait can help us.

Take a look at the Scaladocs for HasVelocity. It extends another trait, HasPos; take a look at that, too. If you didn’t do the optional assignment in Chapter 3.6 that introduced class Velocity, start by reading about that class.

Consider how you could add the HasVelocity trait to the classes Bug and Obstacle in FlappyBug. Consider the implications of doing so. Do so. See below for hints if you want them.

Hints for Obstacle:

• You’ll need an extends at the top, of course.

• The class needs to implement the abstract method velocity as specified in the HasVelocity trait. Add the method. An obstacle’s speed is constant along the x-axis and zero along the y-axis.

• HasVelocity provides a nextPos method. Use it to (re)implement approach.

Hints for Bug:

• You’ll need another extends and another velocity method.

• You can again use nextPos to simplify the code that moves the bug. (You’ll probably either edit fall or the helper method move if you wrote it in an earlier chapter; the latter becomes rather unnecessary with nextPos, though.)

  • Perhaps you’ll also come up with a way to simplify touches in class Obstacle a bit?

A+ presents the exercise submission form here.

Summary of Key Points

• A trait is a programming construct similar to a class. It, too, defines a data type. It, too, is useful for modeling concepts in the program’s domain.

• You can use a trait to represent a superordinate domain concept: the trait defines instance variables and methods that are common to multiple classes and/or traits.

  • A class may inherit one or more traits, giving the class the properties defined in those traits and making those traits its supertypes.

  • Using classes and traits, you can form a “family tree” of concepts, a type hierarchy.

• A trait may define abstract methods. An abstract method doesn’t have a generic implementation (method body) in the trait itself; the trait’s subtypes define separate implementations for the method instead. The presence of an abstract method on a trait guarantees that all actual objects with that trait have some implementation for the method.

• A subtype may override its supertype’s method with a subtype-specific implementation.

• Links to the glossary: trait, abstract method, abstract variable; class hierarchy; static type, dynamic type; DRY; abstraction; to override.

Feedback

Please note that this section must be completed individually. Even if you worked on this chapter with a pair, each of you should submit the form separately.

Time spent: (*) Required

Please estimate the total number of minutes you spent on this chapter (reading, assignments, etc.). You don’t have to be exact, but if you can produce an estimate to within 15 minutes or half an hour, that would be great.

“I feel that I have understood the most important things in this chapter.” (*) Required

fully agree

somewhat agree

somewhat disagree

fully disagree

I’m unable to answer or don’t want to comment.

Written comment or question:

You aren’t required to give written feedback. Nevertheless, please do ask something, give feedback, or reflect on your learning! (However, the right place to ask urgent questions about programs that you’re currently working on isn’t this form but the lab sessions or Piazza. We can’t guarantee that anyone will even see anything you type here before the weekly deadline.)

Credits

Thousands of students have given feedback and so contributed to this ebook’s design. Thank you!

The ebook’s chapters, programming assignments, and weekly bulletins have been written in Finnish and translated into English by Juha Sorva.

The appendices (glossary, Scala reference, FAQ, etc.) are by Juha Sorva unless otherwise specified on the page.

The automatic assessment of the assignments has been developed by: (in alphabetical order) Riku Autio, Nikolas Drosdek, Kaisa Ek, Joonatan Honkamaa, Antti Immonen, Jaakko Kantojärvi, Onni Komulainen, Niklas Kröger, Kalle Laitinen, Teemu Lehtinen, Mikael Lenander, Ilona Ma, Jaakko Nakaza, Strasdosky Otewa, Timi Seppälä, Teemu Sirkiä, Joel Toppinen, Anna Valldeoriola Cardó, and Aleksi Vartiainen.

The illustrations at the top of each chapter, and the similar drawings elsewhere in the ebook, are the work of Christina Lassheikki.

The animations that detail the execution Scala programs have been designed by Juha Sorva and Teemu Sirkiä. Teemu Sirkiä and Riku Autio did the technical implementation, relying on Teemu’s Jsvee and Kelmu toolkits.

The other diagrams and interactive presentations in the ebook are by Juha Sorva.

The O1Library software has been developed by Aleksi Lukkarinen, Juha Sorva, and Jaakko Nakaza. Several of its key components are built upon Aleksi’s SMCL library.

The pedagogy of using O1Library for simple graphical programming (such as Pic) is inspired by the textbooks How to Design Programs by Flatt, Felleisen, Findler, and Krishnamurthi and Picturing Programs by Stephen Bloch.

The course platform A+ was originally created at Aalto’s LeTech research group as a student project. The open-source project is now shepherded by the Computer Science department’s edu-tech team and hosted by the department’s IT services; dozens of Aalto students and others have also contributed.

The A+ Courses plugin, which supports A+ and O1 in IntelliJ IDEA, is another open-source project. It has been designed and implemented by various students in collaboration with O1’s teachers.

For O1’s current teaching staff, please see Chapter 1.1.

Additional credits for this page

Thanks to whoever came up with the original joke that the driving example is based on.

Posting submission...

×

Identical submission

This submission is identical to the previous submission . Are you sure you want to submit it?

Cancel Submit