InstanceType

The InstanceType type can be used as return type for class members to indicate that the member returns a value of the same (or more concrete) type as the instance it is being called on.

This allows for class hierarchies where more concrete descendants can override a method, and (be know to) return more concrete values that match their class. Consider the following example:

type
  Employee = public class
  public
    property Name;
    method Copy: Employee; virtual; 
  end;

  Manager = public class(Employee)
  public
    property Underlings: List<Person>;
    method Copy: Employee; override;
  end;
public class Employee
{
    public string Name { get; set; }
    public virtual Employee Copy() { ... }
}

public class Manager : Employee
{
    public List<Person> Underlings { get; set; }
    public override Employee Copy() { ... }
}
public class Employee {
    public var Name
    public func Copy() -> Employee { ... }
}

public class Manager : Employee
{
    public var Underlings: [Person]
    public override func Copy() -> Employee { ... }
}
public class Employee
{
    public string Name { __get; __set; }
    public virtual Employee Copy() { ... }
}

public class Manager : Employee
{
    public List<Person> Underlings { __get; __set; }
    public override Employee Copy() { ... }
}

In this example of a class hierarchy, the Copy() method can be used to create a copy of a given employee record. But, due to the nature of how traditional polymorphism works, calling Copy on an instance of the more concrete Manager class still returns the base class – requiring unnecessary casting:

var m := lMyManager.Copy();
var u := m.Underlings.Count; // fails
var m = lMyManager.Copy();
var u = m.Underlings.Count; // fails
let m = lMyManager.Copy()
let u = m.Underlings.Count // fails
var m = lMyManager.Copy();
var u = m.Underlings.Count; // fails

Here, we can't access the Underlings property of the cloned Manager, because even though we know that m refers to a Manager, the compiler only knows that m is an Employee.

Simply changing the return type of Copy to InstanceType fixes this:

type
  Employee = public class
  public
    property Name;
    method Copy: InstanceType; virtual; 
  end;

  Manager = public class(Employee)
  public
    property Underlings: List<Person>;
    method Copy: InstanceType; override;
  end;
public class Employee
{
    public string Name { get; set; }
    public virtual InstanceType Copy() { ... }
}

public class Manager : Employee
{
    public List<Person> Underlings { get; set; }
    public override InstanceType Copy() { ... }
}
public class Employee {
    public var Name
    public func Copy() -> Self { ... }
}

public class Manager : Employee
{
    public var Underlings: [Person]
    public override func Copy() -> Self { ... }
}
public class Employee
{
    public string Name { __get; __set; }
    public virtual InstanceType Copy() { ... }
}

public class Manager : Employee
{
    public List<Person> Underlings { __get; __set; }
    public override InstanceType Copy() { ... }
}

Because the compiler knows that lMyManager is a Manager, it know can infer that the result of Copy() will also be a Manager instance. So the following code now works, without cast:

var m := lMyManager.Copy();
var u := m.Underlings.Count;
var m = lMyManager.Copy();
var u = m.Underlings.Count;
let m = lMyManager.Copy()
let u = m.Underlings.Count
var m = lMyManager.Copy();
var u = m.Underlings.Count;

But of course Copy() still behaves fully polymorphically, like any virtual/override method. When calling Copy() on an instance of a Manager that's stored in a variable typed Employee, the same override Copy() method will be called at runtime – but of course in that case, the compiler will merely assume the result is an Employee:

var e := lSomeEmployee.Copy(); // could be a Manager, but we don't know
var u := e.Underlings.Count; // fails! we can't assume e is a Manager, here
var e = lSomeEmployee.Copy(); // could be a Manager, but we don't know
var u = e.Underlings.Count; // fails! we can't assume e is a Manager, here
var e = lSomeEmployee.Copy() // could be a Manager, but we don't know
var u = e.Underlings.Count // fails! we can't assume e is a Manager, here
var e := lSomeEmployee.Copy(); // could be a Manager, but we don't know
var u := e.Underlings.Count; // fails! we can't assume e is a Manager, here

Version Notes

As of Elements 10, InstanceType is now supported on all platforms, not just Cocoa (where it has always been available).