# on 02-Sep-2014 (Tue)

#### Annotation 149631901

 #odersky-programming-in-scala-2ed #scala The == method is essentially the same as equals and != is always the negation of equals. So individual classes can tailor what == or != means by overriding the equals method. We’ll show an example later in this chapter.

#### pdf

cannot see any pdfs

#### Annotation 149631916

 #odersky-programming-in-scala-2ed #scala The root class Any has two subclasses: AnyVal and AnyRef.

#### pdf

cannot see any pdfs

#### Annotation 149631927

 #odersky-programming-in-scala-2ed #scala all value classes are subtypes of scala.AnyVal, but they do not subclass each other. Instead there are implicit conversions between different value class types. For example, an instance of class scala.Int is automatically widened (by an implicit conversion) to an instance of class scala.Long when required.

#### pdf

cannot see any pdfs

#### Annotation 149631938

 #odersky-programming-in-scala-2ed #scala The methods min, max, until, to, and abs are all defined in a class scala.runtime.RichInt, and there is an implicit conversion from class Int to RichInt. The conversion is applied whenever a method is invoked on an Int that is undefined in Int but defined in RichInt.

#### pdf

cannot see any pdfs

#### Annotation 149631949

 #odersky-programming-in-scala-2ed #scala On the Java platform AnyRef is in fact just an alias for class java.lang.Object. So classes written in Java as well as classes written in Scala all inherit from AnyRef.

#### pdf

cannot see any pdfs

#### Annotation 149631960

 #odersky-programming-in-scala-2ed #scala AnyRef defines an additional eq method, which cannot be overridden and is implemented as reference equality (i.e., it behaves like == in Java for reference types). There’s also the negation of eq, which is called ne.

#### pdf

cannot see any pdfs

#### Annotation 149631971

 #odersky-programming-in-scala-2ed #scala Nothing is a subtype of every other type

#### pdf

cannot see any pdfs

#### Annotation 149631982

 #odersky-programming-in-scala-2ed #scala there exist no values of type Nothing

#### pdf

cannot see any pdfs

#### Annotation 149631993

 #odersky-programming-in-scala-2ed #scala  def error(message: String): Nothing = throw new RuntimeException(message)   The return type of error is Nothing, which tells users that the method will not return normally (it throws an exception instead).

#### pdf

cannot see any pdfs

#### Annotation 149632004

 #odersky-programming-in-scala-2ed #scala Because Nothing is a subtype of every other type, you can use methods "returning" Nothing wherever any expression of any type is expected.

#### pdf

cannot see any pdfs

#### Annotation 149632015

 #odersky-programming-in-scala-2ed #scala A trait definition looks just like a class definition except that it uses the keyword trait.

#### pdf

cannot see any pdfs

#### Annotation 149632026

 #odersky-programming-in-scala-2ed #scala A trait can be mixed in to a class using either the extends or with keywords.

#### pdf

cannot see any pdfs

#### Annotation 149632037

 #odersky-programming-in-scala-2ed #scala You can do anything in a trait definition that you can do in a class definition, and the syntax looks exactly the same, except: a trait cannot have any “class” parameters​whereas in classes, super calls are statically bound, in traits, they are dynamically bound.

#### pdf

cannot see any pdfs

#### Flashcard 149632050

Tags
#odersky-programming-in-scala-2ed #scala
Question
You can do anything in a trait definition that you can do in a class definition, and the syntax looks exactly the same, except:
• [...]
• ​whereas in classes, super calls are statically bound, in traits, they are dynamically bound.
a trait cannot have any “class” parameters

status measured difficulty not learned 37% [default] 0

#### Parent (intermediate) annotation

Open it
You can do anything in a trait definition that you can do in a class definition, and the syntax looks exactly the same, except: a trait cannot have any “class” parameters​whereas in classes, super calls are statically bound, in traits, they are dynamically bound.

#### Original toplevel document (pdf)

cannot see any pdfs

#### Flashcard 149632057

Tags
#odersky-programming-in-scala-2ed #scala
Question
You can do anything in a trait definition that you can do in a class definition, and the syntax looks exactly the same, except:
• a trait cannot have any “class” parameters
• [behaviour?]
whereas in classes, super calls are statically bound, in traits, they are dynamically bound.

status measured difficulty not learned 37% [default] 0

#### Parent (intermediate) annotation

Open it
You can do anything in a trait definition that you can do in a class definition, and the syntax looks exactly the same, except: a trait cannot have any “class” parameters​whereas in classes, super calls are statically bound, in traits, they are dynamically bound.

#### Original toplevel document (pdf)

cannot see any pdfs

#### Flashcard 149632068

Tags
#odersky-programming-in-scala-2ed #scala
Question
What are the "class" parameters, the ones that traits cannot have (as opposed to classes)?
for example, in the class Point?
parameters passed to the primary constructor of a class, for example:
class Point(x: Int, y: Int)

status measured difficulty not learned 37% [default] 0

#### pdf

cannot see any pdfs

#### Flashcard 149632079

Tags
#odersky-programming-in-scala-2ed #scala
Question
What does it mean that whereas in classes, super calls are statically bound, in traits, they are dynamically bound?
If you write “super.toString” in a class, you know exactly which method implementation will be invoked. When you write the same thing in a trait, however, the method implementation to invoke for the super call is undefined when you define the trait. Rather, the implementation to invoke will be determined anew each time the trait is mixed into a concrete class.

status measured difficulty not learned 37% [default] 0

#### pdf

cannot see any pdfs

#### Flashcard 149632090

Tags
#odersky-programming-in-scala-2ed #scala
Question
What does it mean to declare a trait which exends a class?

trait Doubling extends IntQueue {
// whatever
}

it means that the trait can only be mixed into a class that also extends IntQueue.

status measured difficulty not learned 37% [default] 0

#### pdf

cannot see any pdfs

#### Flashcard 149632101

Tags
#odersky-programming-in-scala-2ed #scala
Question
How come an abstract method can call super? It would certainly fall for classes.

trait Doubling extends IntQueue {
abstract override def put(x: Int) { super.put(2 * x) }
}

Since super calls in a trait are dynamically bound, the super call in trait Doubling will work so long as the trait is mixed in after another trait or class that gives a concrete definition to the method.

status measured difficulty not learned 37% [default] 0

#### pdf

cannot see any pdfs

#### Flashcard 149632120

Tags
#odersky-programming-in-scala-2ed #scala
Question
What does the combination of method modifiers abstract override mean and where can it be used?
It can be used only in traits and it means that the trait can be only mixed into a class that has a concrete definition of the method that is marked with these modifiers.

status measured difficulty not learned 37% [default] 0

#### pdf

cannot see any pdfs

#### Annotation 149632131

 #odersky-programming-in-scala-2ed #scala Once a trait is mixed into a class, you can alternatively call it a mixin.

#### pdf

cannot see any pdfs

#### Flashcard 149632140

Tags
#odersky-programming-in-scala-2ed #scala
Question
Once a trait is mixed into a class, you can alternatively call it a [...].
mixin

status measured difficulty not learned 37% [default] 0

#### Parent (intermediate) annotation

Open it
Once a trait is mixed into a class, you can alternatively call it a mixin.

#### Original toplevel document (pdf)

cannot see any pdfs

#### Annotation 149632147

 #odersky-programming-in-scala-2ed #scala The order of mixins is significant.Roughly speaking, traits further to the right take effect first.

#### pdf

cannot see any pdfs

#### Flashcard 149632156

Tags
#odersky-programming-in-scala-2ed #scala
Question
The order of mixins is significant.Roughly speaking, traits further to the [...]take effect first.
right

status measured difficulty not learned 37% [default] 0

#### Parent (intermediate) annotation

Open it
The order of mixins is significant.Roughly speaking, traits further to the right take effect first.

#### Original toplevel document (pdf)

cannot see any pdfs

#### Annotation 149632163

 #odersky-programming-in-scala-2ed #scala when a trait gains or loses a member, any classes that inherit from it must be recompiled, even if they have not changed.