Class-Based Languages

• 2.1 Classes and Objects
• 2.2 Method Lookup
• 2.3 Subclasses and Inheritance
• 2.4 Subsumption and Dynamic Dispatch
• 2.5 Type Information, Lost and Found
• 2.6 Covariance, Contravariance, Invariance
• 2.7 Method Specialization
• 2.8 Self Type Specialization

class cell is
  var contents: Integer := 0;
  method get(): Integer is
    return self.contents;
  end;
  method set(n:Integer) is
    self.contents := n;
  end;
end;

• distinguishes between classes and types (important!)

var myCell: InstanceTypeof(cell);

var myCell: InstanceTypeof(cell) := new(cell);

myCell.contents := n;
myCell.set(2 * myCell.get());

• All objects of the same class have exactly the same methods (but not exactly the same attributes, because the values may be different)
• Therefore, they can all share the same method table or method suite

• The attribute records delegate to the method suites for method invocation.
• This technique is called delegation (as opposed to embedding)

Method suites are organized in a 

• tree for single inheritance
• DAG (directed acyclic graph) for multiple inheritance.

But: 

• methods cannot be extracted from objects
• Unsound (read on... [section 2.6])
• methods cannot be updated
• If they could, method update would change only the objects under embedding, but would change all objects of the class under delegation.
• Could be unsound (read on... [section 2.6])

subclass reCell of cell is
  var backup:Integer := 0;
  override set(n:Integer) is
    self.backup := self.contents;
    super.set(n);
  end;
  method restore() is
    self.contents := self.backup;
  end;
end;

• adding the attribute backup to save the last value
• overriding the set() method to save the last value (then call the original set() method to do the job)
• adding the restore() method

Informally, when we say reCell inherits from cell, we mean reCell is a subclass of cell, but reCell may override all methods and inherit nothing. 
 

• methods called from inside methods of an ancestor class may not be the methods of the ancestor class, but may be the methods overridden by some decedent class. 

• When a method is called through super, self is still bound to the original caller.
• There's other ways to access ancestors' methods (e.g. what about languages with multiple inheritance?)

• Method lookup searches up the inheritance chain to find a method
• cell::set() can't be seen from the reCell object
• a call to aReCell.get() will invoke aCell:get()
• Not so with attributes

In statically typed languages, the type is known at compile time, so the method suite can be collapsed: 

• We have to decide what to do about conflicts and duplicates in:
• attributes
• methods
• superclasses
• What is the meaning of super?

var myCell: InstanceTypeOf(cell) := new cell;
var myReCell: InstanceTypeOf(reCell) := new reCell;
procedure f(x: InstanceTypeOf(cell)) is ... end;

myCell := myReCell;
f(myReCell);

• The last two statements would be illegal in C or Pascal, but they are legal in OO languages.  Why?

• Not all languages make the subclassing-is-subtyping assumption (e.g. Java and languages with interfaces)

procedure g(x: InstanceTypeOf(cell)) is
  x.set(3);
end;

g(myReCell);

• based on the compile-time type information

• based on the run-time value of x (called the true type)
• dynamic dispatch is used in all OO languages

• In the example, one cannot "see" reCell::backup and reCell::restore() from inside g() even though its true type is reCell.
• One can only "see" the attributes and methods of cell. 

• e.g. the ability to access reCell::backup is lost in the previous example.

• the overriding set() method can access backup (though self).
• The client still cannot access the hidden information directly.

• typecase
• dynamic casting

• violates object abstraction (reveals private information)
• introduces a form of dynamic failure
• makes code less extensible: new subclasses cause typecases and casts to require recoding.

AxB <: A'xB' provided that A<:A' and B<:B' 

Argument for the covariance of Ax B

• A pair <a,b> with left component a of type A and right component b of type B, has type AxB. 
• If A <: A' and B <: B', then by subsumption we have a:A' and b:B', so that <a,b> has also type A'xB'.
• Therefore any pair of type AxB has also type A'xB' whenever A <: A' and B<: B'. 
• In other words, the inclusion AxB <: A'xB' between product type is valid whenever A<:A' and B <: B'.

A->B is contravariant in its left argument (the parameter) and covariant in its right argument (the result). 

A->B <: A'->B' provided that A' <: A and B <: B' 

Argument for the co/contravariance of A->B

• If B<: B', then a function f of type A->B produces results of type B' by subsumption.
• If A' <: A, then f accepts also arguments of type A', since these have type A by subsumption.
• Therefore every function of type A->B has also type A'->B' whenever A' <: A and B <: B'.
• In other words, the inclusion A->B <: A'->B' between function types is valid whenever A'<:A and B<:B'.

A#B is invariant on both arguments (neither covariant nor contravariant). 

Argument for the invariance of A#B

• If A<:A' and B<:B', can we covariantly allow A#B <: A'#B'?
• If we adopt this inclusion, then from p:A#B we obtain p:A'#B' and we can perform setLft(p,a') for any a':A'.
• After that, getLft(p) might return an element of type A' that is not an element of type A.  Hence the inclusion A#B <: A#B' is not sound.
• Conversely, if A'' <: A and B'' <: B, can we contravariantly allow A#B <: A''#B''? 
• From p:A#B we now obtain p:A''#B'', and we can incorrectly deduce that getLft(p):A''.
• Hence the inclusion A#B <: A''#B'' is not sound either.

• Thus, overriding methods my generalize the types of the parameters.
• It doesn't matter if there are multiple parameters, any number of arguments may be taken as a single tuple (which works [covariantly] just like a pair, AxB) argument.

• Thus, overriding methods may:
• specialize the return type and 
• generalize the parameters.

• Thus, subclasses may not tamper with the types of non-method attributes.

• e.g. Eiffel still has covariant method arguments.
• e.g. Visual C++ has invariant method return types
• It is amazing that there is any argument, given that method co/contravariance is direct consequence of subsumption.

We can think of methods as functions with a hidden first parameter that carries the self reference. 

• the self argument varies covariantly.
• any inheritable pre-method of type (InstanceTypeOf(c)xA)->B has by subsumption the type (InstanceTypeOf(c')xA')->B' for any A'<:A and B<:B'. (p.23)

Consider a method that recursively returns its own type: 

class c is
  var x: Integer := 0;
  method m(): InstanceTypeOf(c) is ... self ... end;
end;

class c' of c is
  var y:Integer := 0;
end;

We can recode c: 

class c is
  var x: Integer := 0;
  method m(): Self is ... self ... end;
end;

But... see section 3.4 and 3.5