Inheritance and Subtyping

This boilerplate repetition that you refer to is only necessary when doing composition because the languages don't provide the requisite syntactic sugar for it, the way they do for inheritance. This is very unfortunate but totally fixable.

There are more interpretations of "OO" than there are people, but the overall direction is that OO isn't a panacea for code maintainability, and some frameworks ahem Spring create a mental model at times so distant from OOP, that I might as well have written everything in Python. I gain nothing from having classes when one half are records and the other half are singletons.

Inheritance is just a tool. It’s insane to reject it outright just because someone can use it incorrectly. It does some things extremely well and better than composition.

True.

Also this:

"Because Animal is a Protocol, any class that defines feed() becomes an Animal"

is slightly incorrect.

By default, protocols are only relevant for static type analysis, but you _can_ enable runtime instance checking using the @runtime_checkable decorator.

(So you can do "if isinstance(foo, Animal):...", but AFAIK this decorator comes with a performance penalty)

> described is slightly wrong?

Shhhh! You're spoiling how it's the most interesting language the author knows in terms of inheritance.

you mean CLOS (Common Lisp Object System) ?

There are others that are also _very_ interesting (but also pre 90s). SELF fe, was object oriented, but did not have inheritance. It used prototypes. In essence, you would create something of the same "type" by cloning the prototype.

Anyway, subtyping and inheritance are similar, but not identical, concepts. Also, some languages provide traits iso protocols (and maybe even both ?). Some languages provide functors. The goal is always the same: abstract commonalities. Let's just keep it at: "it's complicated" ;)

I think it's better to study the design mistakes of programming languages in a historic context. For example: C++ offers multiple inheritance. This caused the diamond problem. Java tried to fix this via interfaces. This fixed the problem, but was also a mistake as interfaces cannot provide behaviours. So Multiple inheritance is not an issue if only 1 of the parties provides state; all others can provide signatures but also behaviours.

Python is probably the most CLOS-like language in common use tho, isn't it? Multiple inheritance, metaclasses, the ability to decorate functions. No built-in multiple dispatch but I'm pretty sure I saw some implementations of that too over the years :)

Someone also doesn't know Python?

Isn't it the case that if we have an obj and its class has a feed method, we can call obj.feed(...) regardless of what it inherits from?

Someones doesn't know Common Lisp.

that said most people don't know about things predating the 90s

> Go interfaces are explicit, not implicit, the difference is more where they are defined.

That's not what the blog author wrote so what are you responding to? What they actually wrote:

>> If a Go struct implements the same functions as an interface, it implicitly implements the interface.

And that's correct except they use the term "functions" instead of "methods". But most people won't get confused by that distinction.

https://go.dev/tour/methods/10 - "Interfaces are implemented implicitly"

I haven't used kotlin. How does it help it?

So the kicker in imperative OO for composition is that the class you are composing has some state / instance vars.

How do you include methods that can view/update those instance vars?

Sure it's easy to compose with static/pure functions.

Do you enclose the instance vars in holder classes and pass those holders to the composition implementation class in it's method signature?

In the end, inheritance or composition is about constructing a class /struct/whatever with a given set of expected signatures with some ideally documented guidance on any intricacies.

From one point of view, yes.

Another point of view is that it's a new kind of de-encapsulation.

Apparently this is a 'global' variable:

    int variable = 0;
    void foo() {
      variable++;
    }
    void bar() {
      variable++;
    }

  class MyClass {

    int variable = 0;
    void foo() {
      variable++;
    }
    void bar() {
      variable++;
    }

  }

The Common Lisp Object System disagrees with functions being attached to data.

Personally I like to differentiate subclassing from conforming to an interface. Both are subtyping, but interfaces are much cleaner.