3 ms·

I also distinctly remember even in my intro-to-OOP programming book, it was explicitly called out that mathematical-isa relationships (the square/rectangle/para

I also distinctly remember even in my intro-to-OOP programming book, it was explicitly called out that mathematical-isa relationships (the square/rectangle/parallelogram case was the one they used in that example) don't qualify as is-a relationships for the purposes of OOP!

nerdponx 2y ago
FWIW I think that's the essence of the complaint here: "is a" can mean various things in various contexts, but Liskov substitution principle and OOP design generally requires it to mean something specific, and using "OOP is a" when you meant another "is a" is an easy trap to fall into, because the language makes it so easy to do. But I don't see why this is a complaint about OOP in general. It's a complaint specifically about inheritance. That said, the claim that integers "are" naturals is mathematically 100% false as well, so the example in the article is also kind of a silly straw man.
- mrkeen 2y ago
  > That said, the claim that integers "are" naturals is mathematically 100% false as well, so the example in the article is also kind of a silly straw man. That's what the article said though.
mjevans 2y ago
I agree, I do not see a natural object relationship between the types of numbers. 'Natural' (unsigned int) numbers might be a building block of signed integers, fractional pairs, and composed floating point types; but they seem like three distinct use cases, with perhaps a way of converting a whole fraction or positive signed number into another type either if it fits, or with an accepted loss of information. When OOP was covered in classes years ago the typical example was something like... Class Animal Class Pet extends Animal Class Dog extends Pet Class Cat extends Pet etc Edit: These days I prefer golang's example of Interfaces which specify what methods and members must exist for something to be 'used as an X'; very useful IOReader IOWriter and https://pkg.go.dev/io#ReadWriter https://pkg.go.dev/io#ReadWriter which naturally is an Interface containing only a Reader and Writer
- readthenotes1 2y ago
  Yeah,Pet extends Animal is just sad...

nerdponx 2y ago

FWIW I think that's the essence of the complaint here: "is a" can mean various things in various contexts, but Liskov substitution principle and OOP design generally requires it to mean something specific, and using "OOP is a" when you meant another "is a" is an easy trap to fall into, because the language makes it so easy to do. But I don't see why this is a complaint about OOP in general. It's a complaint specifically about inheritance. That said, the claim that integers "are" naturals is mathematically 100% false as well, so the example in the article is also kind of a silly straw man.

mrkeen 2y ago
> That said, the claim that integers "are" naturals is mathematically 100% false as well, so the example in the article is also kind of a silly straw man. That's what the article said though.

mjevans 2y ago

I agree, I do not see a natural object relationship between the types of numbers. 'Natural' (unsigned int) numbers might be a building block of signed integers, fractional pairs, and composed floating point types; but they seem like three distinct use cases, with perhaps a way of converting a whole fraction or positive signed number into another type either if it fits, or with an accepted loss of information. When OOP was covered in classes years ago the typical example was something like... Class Animal Class Pet extends Animal Class Dog extends Pet Class Cat extends Pet etc Edit: These days I prefer golang's example of Interfaces which specify what methods and members must exist for something to be 'used as an X'; very useful IOReader IOWriter and https://pkg.go.dev/io#ReadWriter https://pkg.go.dev/io#ReadWriter which naturally is an Interface containing only a Reader and Writer

readthenotes1 2y ago
Yeah,Pet extends Animal is just sad...