[naasking]

> Implementing an interface is not the same thing as inheritance.

Correct, but typical OO languages implement interfaces via inheritance since that's the only means of extension.

The problem with inheritance is that it conflates subtyping with subclassing. These are separable concerns, so with interfaces you get proper subtyping without subclassing, but you can't typically have subclassing without subtyping which is why inheritance should generally be avoided.

[zwieback]

"Typical OO languages" meaning statically typed? I've struggled with all the problems discussed here in C++ and C# but not in Python or Ruby.

[nexys]

What is the difference between subtyping and subclassing? It looks confusing to me.

[naasking]

Subtyping describes an abstraction with which you can substitute any implementation that conforms to that abstraction's signature (Liskov substitution). Subclassing instead typically imposes both subtyping and behavioural inheritance. So as a rough approximation:

Interface implementation = subtyping

Class inheritance = subclassing + subtyping, ie. inheriting behaviour + subtyping

An OO language where you were forced to specify subtyping by implementing interfaces, but you could separately declare some implementations you inherited from without that also applying a subtyping relationship with those types, then that would be a proper separation of concerns.

Oleg discusses the issues in further detail here: http://okmij.org/ftp/Computation/Subtyping/

[zwieback]

Oversimplifying for this context: subclassing is reusing the implementation of a parent class, subtyping is when a type can be substituted for a (parent) class for some given functionality. It's confusing because it's not always easy to explain what constitutes "substitute", e.g. see "Liskov Substitution Principle". In some languages there might not be any class or interface relationship between subclasses - they just have the right functions that do the right things.

[kroltan]

As I understand it, subtyping is the actual conflation of interfaces (not necessarily a syntatical `interface`, but in the logical sense of "exposed things") into one type, and subclassing is direct extension, the so-called "is a" constraint.

For example, in Rust, there is no subclassing: There is no concrete type that is also another type. But there is subtyping, that is, a concrete type can be used where a interface (in Rust, called `trait`) is required, granted it implements that interface. Additionally, external sources can implement their interfaces unto existing external types.

In C#, you have subtyping+subclassing, but only as one. That is, you can have a concrete type B that is an A, and if A implements X, then B implements X. But you can't implement Y for A unless you have access to A's source. So if you want a type that is an A but also does Y, you _have_ to subclass A as a B, and implement Y on B.

[steveklabnik]

The only subtyping in Rust, in my understanding, is lifetimes with the : syntax. Traits are not subtypes.

[lmm]

What's the distinction you're drawing? Certainly with "impl trait", any concrete type that conforms to "Iterator<Item = i32>" seems to be a subtype of "impl Iterator<Item = i32>" in every meaningful sense (e.g. Liskov substitutability).

[steveklabnik]

I’m not drawing a distinction, I’m repeating what those who know more about types than me say. Maybe those people are wrong, but if so our docs need updated!

(I think it’s because traits aren’t types, and therefore can’t be subtypes. But I’m not 100% sure and my copy of TAPL is thousands of miles away at the moment...)

[kroltan]

Ok, I guess, this only works with trait objects or generics, so traits themselves aren't types in the formal sense (as suggested by others. I am not a type system expert nor do I have formal CS theory education).

As I understand (which again, might be flawed, please correct me), it would be more better to say that a type parameter bounded by a trait is a type, and a type implementing that trait is a subtype of the parameter?

But trait objects have types, and such can be subtyped, correct? That is, I can use a `&Bar` where a `&TraitFoo` is expected if `impl TraitFoo for Bar`.

[naasking]

Traits are subtyped, they are simply a restricted kind of value that makes them more tractable than general value subtyping.

[taeric]

Perhaps an example? List<String> is a subtype of List, ArrayList is a subclass?

Question marks, because I am not 100% that I have it correct, either. Hoping someone will correct. :)