Why records must be sealed

Posted on Updated on

When most people (and I include myself in this) start to learn a functional programming language like F#, they are immediately surprised by the lack of inheritance. It’s such a mainstay of our daily programming that we’re initially nonplussed when it’s taken away… In this post I want to talk about the problems introduced by mixing inheritance with the notion of structural equality, and thus why any language which implements the concept of a record type must also prohibit inheritance of such a type.

For the record (ahem), a record is a type where one simply declares the shape of the class (i.e. the names and types of the public members), and then the constructor, equality and hashcode methods are generated for you by the compiler. An example in F# might be this:

type PersonName = { firstName : string; surname : string }

which is roughly equivalent to the following C#:

public sealed class PersonName : IEquatable<PersonName >
{
	public string FirstName { get; }
	public string Surname { get; }

	public PersonName (string firstName, string surname)
	{
		FirstName = firstName;
		Surname = surname;
	}

	public bool Equals(PersonName other) =>
		other != null &&
		other.FirstName == this.FirstName &&
		other.Surname == this.Surname;

	public override bool Equals(object other) =>
		this.Equals(other as PersonName );

	public override int GetHashCode() =>
		FirstName.GetHashCode() ^ Surname.GetHashCode();
}

So a record is just a specific kind of class, why would allowing inheritance of this class cause a problem? Let’s imagine a simple object to model a Cartesian point:

public class Point : IEquatable<Point>
{
	public int X { get; }
	public int Y { get; }

	public Point(int x, int y)
	{
		X = x;
		Y = y;
	}

	public bool Equals(Point other) =>
		other != null &&
		other.X == this.X &&
		other.Y == this.Y;

	public override bool Equals(object other) =>
		this.Equals(other as Point);

	public override int GetHashCode() =>
		X.GetHashCode() ^ Y.GetHashCode();
}

This looks good: it implements the IEquatable<> interface as well as overriding object.Equals(), and we can show that two points with the same x and y values are considered equal, as one would expect:

	var a = new Point(1, 2);
	var b = new Point(1, 2);

	Console.WriteLine(a.Equals(b)); // -> True

However, the point class is not marked as sealed, meaning that (anyone) is free to derive this class and potentially break the concept of equality for our Point class. Suppose someone consumes our class library and introduces a new type: Point3D.

public class Point3D : Point, IEquatable<Point3D>
{
	public int Z { get; }

	public Point3D(int x, int y, int z) : base(x, y)
	{
		Z = z;
	}

	public bool Equals(Point3D other) =>
		other != null &&
		other.X == this.X &&
		other.Y == this.Y &&
		other.Z == this.Z;

	public override bool Equals(object other) =>
		this.Equals(other as Point3D);

	public override int GetHashCode() =>
		X.GetHashCode() ^ Y.GetHashCode() ^ Z.GetHashCode();
}

Again, all looks good:

	var a = new Point3D(4, 5, 6);
	var b = new Point3D(4, 5, 6);

	Console.WriteLine(a.Equals(b)); // -> True

But hang on… if we stop and think about the type hierarchy that we’ve created, it’s already starting to look a bit weird. A Point3D is IEquatable<Point3D>, as you’d expect, but because it inherits from Point it also implements IEquatable<Point>. That means that you can compare a Point3D and a Point for equality, which doesn’t really make sense, but sure enough:

void Main()
{
	var a = new Point(4, 5);
	var b = new Point3D(4, 5, 6);

	Console.WriteLine(a.Equals(b)); // -> True
}

This isn’t right any more. We’ve compared two objects of different types but they’ve returned Equals() -> True. But, here’s the thing about polymorphism: when the Point.Equals(Point) method is executed, we don’t know whether the object that was passed in is actually a Point or whether it’s an instance of some other class that derives from Point, so we can’t actually calculate equality. The only real solution to this (beyond a bit of a hack in the equality method to call GetType on both objects) is to make sure that the class Point can have no inheritors.

In an object oriented language like C#, the rule might be expressed as “any type that implements one or more equality methods must also be sealed”.

There’s one more nail in the coffin for this implementation, we have lost the commutativity of the equals method:

a.Equals(b) // -> True
b.Equals(a) // -> False

Now that’s just all kinds of wrong.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s