This matches my experience: ontological inheritance gets in the way. What we actually want is traits. What can something do, not what it is.

This seems like structural subtyping? Are these synonyms?

I think traits (as I know them) are still nominal subtyping. E.g.: a Rust struct implementing a next() method does not implement the Iterator trait even if they are structurally equivalent. You have to explicitly implement the trait.

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 only sub typing in Rust is lifetimes; other types have no sub typing.

Traits are “ad hoc polymorphism”.

Which is another way of saying that the domain model is what determines the properties of polygons that actually matter. You may have two classes, Square and Rectangle, and they may be mutually incompatible because you need to represent the shape of a hole and the shape of a plug. In that case your square isn't compatible with a rectangular shape even though it's a type of rectangle.

I think the author is saying that sometimes people are unclear about the domain model, and OO doesn't really give you any tools to reason about the model that you don't have in imperative languages, so it's not really an improvement. Fancy type systems are not a substitute for understanding the thing you're reasoning about.

> Fancy type systems are not a substitute for understanding the thing you're reasoning about.

And now you got me wondering about all the times I wrote a Haskell type, some bugged code, mindlessly changed code until the compiler stopped complaining, and it worked flawlessly.

But I guess your comment was about that "writing the types" stage. There were a few times I mindlessly wrote them too based on where they would be used (I could have the compiler give me them, but I'm not used to it). I can remember a few times I did both on the same functions, mindlessly write the types and the implementation.

> No, no: "If you ask me for any object that can have independent width and height, and you reject a Square, you are..." right, of course. It depends on the properties that define what a Rectangle and a Square are in your code.

I think you nailed an important distinction here, but maybe used the wrong words in doing so. The correct definition of a rectangle, with this interpretation, is any object that can change its width and height independently.

I'm just not sure that this is such a sensible definition of a rectangle.

In my mind, the word "rectangle" is a description of how things are in this instant, not a description of in which ways something can change in the future. The latter is a valid concept and something we need a word for, but I'm not sure "rectangle" is such a good candidate.

This also opens up for a solution to the problem:

- In the first sense, rectangle > square. A rectangle has four straight angles, and squares are rectangles where both lenghts happen to be the same.

- In the second sense, square > rectangle. Squares are things which can be scaled, and rectangles are squares which can scale each axis independently.

I don't think the "that can change" characteristic is important here.

You can declare that "for all values of width and height, w does not have to equal h" to be valid. Mutability is irrelevant.

But a rectangle as traditionally defined can have equal dimensions. Consider the rectangle whose width slowly grows to be longer than the height. Surely it does not skip a value because it happens to equal the height?

"does not have to be equal" != "can't be equal".

The set of all possible rectangles have w and h that can be different (or the same) values.