Advanced Class-Based Features

• 3.1 Object Types
• 3.2 Distinguishing Subclassing from Subtyping
• 3.3 Type Parameters
• 3.4 Subclassing without Subtyping
• 3.5 Object Protocols

• Inheritance
• Subclassing
• Subtyping

Later languages (C++ and more so, Java) tend to separate specification and implementation. 

• Better for separate code development in large development teams

How to describe this?  The only thing that is shared is the type signature of class cell. 
 

We can take the object protocol as the type of the object 
 

ObjectType Cell is
  var contents: Integer;
  method get(): Integer;
  method set(n:Integer);
end;

ObjectType reCell is
  var backup:Integer;
  method get(): Integer;
  method set(n:Integer);
  method restore();
end;

• Suitable to describe interfaces
• Can be implemented in more than one way.

1. subtyping based on type structure
2. subtyping based on type names in declarations

O' <: O   if O' has the same components as O and possibly more.

This doesn't take into account the co/contravariance of methods. 

We need to be especially careful with recursive types 
 

•  This is just a reformulation of the ObjectTypeOf property, and is the same as the subclassing-is-subtyping property, but with single implication instead of double implication.

• leads to more flexible subsumption (allowing use of interfaces)
• maintains soundness

• Not really an exclusively object-oriented technique
• Common on modern OO languages

ObjectType Person is
  ...
  method eat(food:Food);
end;

ObjectType Vegetarian is
  ...
  method eat(food:Vegetables);
end;

The method specialization of Vegetarian::eat() violates the contravariance of parameters. 

• If a Vegetarian object is subsumed into a Person object we might legally make the Vegetarian eat meat.

ObjectOperator PersonEating[F <: Food] is
  ...
  method eat(food:F);
end;

ObjectOperator VegetarianEating[F <: Vegetables] is
  ...
  method eat(food:F);
end;

• VegetarianEating[Vegetables] is a type
• VegetarianEating[Food] is not well-formed
• Vegetarian[Vegetables] = Vegetarian
• VegetarianEating is not a type (VegetarianEating cannot have any instances)
• No inclusion relation between PersonEating and VegetarianEating

and this means "a vegetarian is a person that only eats vegetables." 
 

ObjectType Person is
  type F <: Food;
  ...
  var lunch:F;
  method eat(food:F);
end;

ObjectType Vegetarian is
  type F <: Vegetables;
  ...
  var lunch:F;
  method eat(food:F);
end;

We can build an object with the attribute lunch instantiated, then forget about the specific type F. 

Now, Vegetarian <: Person holds as long has we restrict ourselves to only feeding the people the food the they carry with them. 
 

We can completely unlink the notions of subtyping and subclassing 

This is called subclassing-is-not-subtyping. 
 

ObjectType Max is
  var n: Integer;
  method max(other: Max): Max;
end;

ObjectType MinMax is
  var n: Integer;
  method max(other: MinMax): MinMax;
  method min(other: MinMax): MinMax;
end;

class maxClass is
  var n: Integer := 0;
  method max(other: Self): Self is
    if self.n > other.n then 
      return self else return other
    end;
  end;
end;

class minMaxClass of maxClass is
  method min(other: Self): Self is
    if self.n < other.n then 
      return self else return other
    end;
  end;
end;

Therefore: 

Two (equivalent) alternatives: 

• F-bounded parameterization
• higher-order bounded parameterization

ObjectOperator MaxProtocol[X] is
  var n: Integer;
  method max(other: X): X;
end;

ObjectOperator MinMaxProtocol[X] is
  var n: Integer;
  method max(other: X): X;
  method min(other: X): X;
end;

• T-Protocol is a function over types.

Subprotocol: 

To bound the parameterization: 

• We could instantiate as P₁[MinMax]

Then: 

Subprotocol: 

To bound the parameterization: 

• We could instantiate as P₂[MinMaxProtocol]

• it's obvious that there is a subprotocol relation
• it's obvious that subprotocol is a relation between operators, not types

where the instantiation P₃[MinMax] is legal.