Inheritance Often Doesn't Make Sense

People in this thread are trying to separate the concept of mutation from the concept of inheritance, but the problem with this is that you can't separate the two. Consider the following pseudocode:

    Rectangle r = new Rectangle(height = 3, width = 5);
    Square s_as_s = new Square(side = 4);
    Rectangle s_as_r = s_as_s;

    print(r.height); // prints 3
    print(r.width);  // prints 5
    print(s_as_s.height); // prints 4
    print(s_as_s.width);  // prints 4
    print(s_as_r.height); // prints 4
    print(s_as_r.width);  // prints 4
    print(r is_a? Square); // prints false
    print(s_as_s is_a? Square); // prints true
    print(s_as_r is_a? Square); // prints true

Okay, so the question comes up when you mutate these results:

    r.height = 2;
    s_as_r.height = 2;

Keep in mind, this is a perfectly reasonable thing to do in both cases: you're just making two rectangles a little shorter. But no matter how you handle this situation, the results are surprising:

One way:

    print(r.height); // prints 2
    print(r.width);  // prints 5
    print(s_as_s.height); // prints 2
    print(s_as_s.width);  // prints 2
    print(s_as_r.height); // prints 2
    print(s_as_r.width);  // prints 2
    print(r is_a? Square); // prints false
    print(s_as_s is_a? Square); // prints true
    print(s_as_r is_a? Square); // prints true

This is the simplest to implement, but only because there's a part of the contract of Rectangle which is implied and not enforced by the compiler. When we change the height of a rectangle, we don't expect the width to change. This is the sort of gotcha that needs to be put in the documentation in big red letters: "WARNING: CHANGING THE HEIGHT MAY CHANGE THE WIDTH IN SOME SITUATIONS."

Another way:

    print(r.height); // prints 2
    print(r.width);  // prints 5
    print(s_as_s.height); // prints 2
    print(s_as_s.width);  // prints 4
    print(s_as_r.height); // prints 2
    print(s_as_r.width);  // prints 4
    print(r is_a? Square); // prints false
    print(s_as_s is_a? Square); // prints true
    print(s_as_r is_a? Square); // prints true

But now you've broken the contract of Square: the user is going to be very surprised when changing the side of one side of a Square means that the Square instance no longer represents a square.

Okay, what about this:

    print(r.height); // prints 2
    print(r.width);  // prints 5
    print(s_as_s.height); // prints 2
    print(s_as_s.width);  // prints 4
    print(s_as_r.height); // prints 2
    print(s_as_r.width);  // prints 4
    print(r is_a? Square); // prints false
    print(s_as_s is_a? Square); // prints false
    print(s_as_r is_a? Square); // prints false

This might be possible with some horrible hack in a language that does dynamic typing. This maintains the contracts of all the types, but I'd argue that it breaks the contract of the language itself: it's deeply confusing to have the type of the s_as_s variable change out from under you.

Perhaps you could do this:

    print(r.height); // prints 2
    print(r.width);  // prints 5
    print(s_as_s.height); // prints 2
    print(s_as_s.width);  // prints 2
    print(s_as_r.height); // prints 2
    print(s_as_r.width);  // prints 4
    print(r is_a? Square); // prints false
    print(s_as_s is_a? Square); // prints true
    print(s_as_r is_a? Square); // prints false

Setting aside how one might even implement this, we've now got the surprising result that s_as_s and s_as_r seem to be different instances now.

Maybe we should have prevent this in the first place:

    r.height = 2; // works
    s_as_s.height = 2; // throws CannotSetSideViaHeightException
    s_as_r.height = 2; // throws CannotSetSideViaHeightException

s_as_s.height = 2 throwing an exception sort of makes sense, but now s_as_r isn't behaving like a rectangle--we're breaking the Rectangle contract again.

Another way to prevent it:

    r.height = 2; // works
    s_as_s.height = 2; // works
    s_as_r.height = 2; // throws ThisWouldBeConfusingException

Again you're breaking the contract of the language, that s_as_s and s_as_r seem to be different objects.

There's only one way left I can think of to make Rectangle maintain its contract, Square maintain its contract, and keep s_as_s and s_as_r behaving the same way:

    r.height = 2; // throws MutationException
    s_as_s.height = 2; // throws MutationException
    s_as_r.height = 2; // throws MutationException

Does this look familiar? It should: it's basically immutability implemented as checks at run time, which is not a good way to implement it. At this point we should just implement these as immutable objects.

I'm not necessarily saying that immutability is the only way. You could also give up inheritance:

    Rectangle makeSquare(int side) {
      return new Rectangle(side, side);
    }

    Rectangle r = new Rectangle(3, 5);
    Rectangle s_as_r = makeSquare(4);

    print(r.isSquare); // prints false
    print(s_as_r.isSquare); // prints true

    r.height = 2;
    s_as_r.height = 2;

    print(r.height); // prints 2
    print(r.width); // prints 5
    print(s_as_r.height); // prints 2
    print(s_as_r.width); // prints 4

    print(r.isSquare); // prints false
    print(s_as_r.isSquare); // prints true

This also results in unsurprising behavior.

More like interfaces. A lot of OOP languages just did it in a limited way where interfaces for a class are closed. Meanwhile in Haskell or Rust, you can define your interfaces, and then provide implementations of it for existing objects like String. Or the Scale workaround, which basically is implicitly converting to wrapper classes that implement the interface. With the goal being extending existing types with new shared behavior, without the limitations of full inheritence.

The carpenter has certainly altered the dimensions of the board, but in so doing has he not destroyed the old rectangle and created a new one?

Duck typing is central to the Smalltalk "vision thing". That and the idea that a message is a symbolic representation of a method, which an object may or may not support. It is not, in fact, the method, nor does it stand for a direct call to the method. In C++ and Java, for a call to a.foo(12) the compiler can look up the class of a, determine whether it has a foo implementation, and if so compile a call directly with the number 12. In Smalltalk, a foo: 12 has no such implications. Rather the runtime will look up whether a's class has a foo: method at call time and if so, invoke that method; otherwise invoke the object's doesNotUnderstand: method with the message and arguments as parameters. There's an added layer of indirection there. It's rather like a single-threaded Actor model. Kay was trying to get people to think in terms of encapsulated objects that communicate in (often ad hoc!) ways, not in terms of inheritance trees or type hierarchies.

Is it better? Is it worse? I don't know. We know Smalltalk is slower, but it (along with Objective-C) admits designs unfathomable in C++. For example, all objects that understand a given protocol (set of methods) and implement it in a sensible way are substitutable with each other (with respect to the protocol) irrespective of their place on the inheritance hierarchy (or even whether such protocol was formally defined). This is NOT true with C++, absent template metaprogramming, and it's not true with Java unless you define an interface and assert that all classes which understand those methods implement that interface.

Furthermore, by overriding doesNotUnderstand:, you can specify a behavior for classes when sent a message they don't have a method for, besides raising an error. Maybe you want them to forward the method to one or more delegate objects, or log the invocation.

It's super-flexible, powerful, and neat in a similar dynamic-language way to how Lisp is neat. That's why Smalltalk attracts so many fervent converts. As I said, it can be better or worse depending on your perspective. Some people like working with type hierarchies; Haskell, Rust, and even C++ attract fervent converts too!

I think this means doing composition/delegation, which the author of TFA calls "basically giving up on implementation inheritance."