The Impoliteness of Overriding Methods (2012)

A "method combination" determines, when a generic function call denotes multiple methods, in which order they are called.

There is a default method combination with standard features: :pre/:post/:around auxiliary methods in relation to a primary method. This has the conventional ordering: derived controls dispatch. E.g. an :around method can decide that the primary method won't be executed at all by not calling (call-next-method).

The documentation for the define-method-combination macro is a bit of a challenging read. One of the examples of its "long forms" shows how the standard method combination would be defined with this macro, if it didn't exist. A simple example shows how to arrange for methods to be dispatched one by one until one returns something other than nil.

The thing is, the developer doing the overriding generally has more information about the final system than the original - after all, the code is more specific. So taking away their power is generally problematic.

I could see it being useful if it was optional. Something like:

    class ScaryMonster extends GameObject {
      void render(Renderer renderer) {
        super(function() {
            renderer.drawImage(Images.SCARY_MONSTER);
        });
      }
    }

In OOP, the only reason for something to be a "subclass" of something else, is that you first had several subclasses (FooA, FooB, FooC) as plain classes, and then noticed that they all obeyed the exact same interface (a hypothetical IFoo) and had common logic, and so you then took the opportunity to factor out the interface + common logic into a common superclass (Foo).

The interface, if separated into an abstract contract (a real IFoo) is reusable by downstream code; but the common logic, 99% of the time, isn't. (It's potentially reusable by people contributing to your library, but more-than-likely they'll have to modify the "shape" of your common logic when they add a new concrete subclass with its own new concerns, even if the contract IFoo would stay the same.)

Given a full prover-level type system, you would be essentially unable to usefully do anything with the superclass Foo once it's been created, other than what the "causally prior" subclasses FooA, FooB, and FooC are already doing with it. Foo is the reificiation of an equivalence class whose members are exactly FooA, FooB, and FooC. A "FooD" shouldn't be able to be defined without changing the definition of Foo.

Assuming you accept this, how does code reuse work?

• Specializing behavior: this is what the delegate pattern (composition!) is for. Rather than SomeLib exposing a base class SomeLib.Foo for subclassing, SomeLib instead gives you a (final, sealed) SomeLib.Foo class which takes a SomeLib.IBar as a delegate, and calls methods on it. You create YourLib.Bar that implements SomeLib.IBar, and pass it to the constructor of a new SomeLib.Foo.

• Extending behavior: this is what plain-old component-wise composition is for. Call it an Adapter, or a Decorator, or a Facade; it's just a new object of a class you've defined, that is implemented by holding onto an instance of the (final, sealed) SomeLib.Foo class. (If you want nice interoperation, the upstream library author should provide a SomeLib.IFoo interface and define their methods to take/return it; and you should have your wrapper class implement SomeLib.IFoo. In less statically-typed languages, this translates to adding a contract method to your object that can be probed for, e.g. Ruby's #to_str.)

E.g. Eric Lippert's comments: https://blogs.msdn.microsoft.com/ericlippert/2004/01/22/why-...

A StackOverflow q&a: https://stackoverflow.com/questions/268251/why-seal-a-class/...

Pro: sometimes it lets you extend classes in useful ways that the original author didn't anticipate. Con: it makes it difficult or impossible to reason about invariants in the base class.

Seems like it's a trade-off between hack-ability and robustness.

This means inheritors only need to ensure they implement according to the specified constraints.

I also suspect some of the new C++14 and beyond meta tagging can even enforce a `final`.

    class Abstract {
     public:
      // Even though this function might do nothing but
      // redirect, it is a useful abstraction.
      void
      SomeMethod() {
        // Do things which must be done first, if any.
        ImplSomeMethod();
        // Do things which must be done after, if any.
      }

     protected:
      // Document all expected invariant behavior here.
      virtual void
      ImplSomeMethod() = 0;
    };

Unfortunately the majority of OOP books don’t emphasize this, so beginners try to do everything by subclassing, as if that was what OOP is about...

If he started with; say “in javascript” I’d agree completely.

And I know that unless you‘re writing code for others to use (SDK, os ..) you usually don’t need inheretance.

But for generations people overridden methods and no one complained about it... infact it’s a good idea in so many cases and easily any proper OOP class can protect it’s behaviour (see encapsulation ..)

The only impolitness I see here is someone refusing a very valid pattern in a very solid space just because it’s invalid in js (where a lot of things are invalid)