4 ms·

> A language is OO if it supports two things Yes, but only in your personal opinion. I disagree. As I've said clearly, for me a language is not OOP without inh

> A language is OO if it supports two things Yes, but only in your personal opinion. I disagree. As I've said clearly, for me a language is not OOP without inheritance. Go is not an OOP language. This is important for me because I like Go and think it's a great non-OOP language. In contrast, if Go was an OOP language, then it would be a really bad one - no traits, no mixins, no classes, no multiple inheritance, no multiple dispatch, no true dynamic method dispatch (see below), etc. Besides, treating Go as if it was an OOP language often leads to horrible Jave-in-Go programming style. Btw, I wasn't talking about C++ inheritance, I had things like CommonLisp CLOS and Ada's tagged types in mind. CL's OOP is among the most powerful because it has multiple dynamic dispatch and a metaobject protocol. Go lacks both, and it also doesn't really have dynamic dispatch. Dynamic dispatch means that superclass and subclass methods can be called at runtime depending on what is needed. You cannot call various superclass methods of a Go struct because Go structs do not have a type hierarchy/superclasses as there is no concept of inheritance. You sometimes get something that looks similar because of the duck typing (which is dynamic, but it's still not a full method dispatch) and because you can downcast at runtime using .(type). But that's still not the same as dynamic dispatch in an OOP language. Here is an explanation of the difference: [1] However, if you insist on imposing your definition as the one and only right one, then that's okay for me. In that case, Go is the most limited and crippled OOP language I've ever used, and so be it. [1] https://stackoverflow.com/questions/49114057/idiomatic-way-to-mimic-proper-dynamic-dispatch-in-go https://stackoverflow.com/questions/49114057/idiomatic-way-t...

quietbritishjim 3y ago
I suppose we've got bogged down in semantics here (in fairness that's the point of the original article). I agree that Go is not a good language for OO and that's fine because it's not meant to be. But definitions aren't really a matter of opinion. If it's my opinion that apples count as a variety of orange, then that doesn't make me right. Instead, they're defined by what is widely understood by that term. I'm not saying what I've written is authoritative but it was what I was taught at university by someone who was around and academically active when OO languages were being invented (that course had a lot of SmallTalk D-: ) and certainly is a much closer match to how I've usually seen it used since compared to yours. BTW I'm primarily a C++ (and Python and C#) developer, I hardly know Go, so I have no axe to grind here. > Dynamic dispatch means that superclass and subclass methods can be called at runtime depending on what is needed. No it doesn't: it doesn't require the notion of superclass and subclass. Using an interface to call a method still counts as dynamic dispatch. > Here is an explanation of the difference: [1] The thing is, the question asks "does Go support dynamic dispatch" but the answers are about the subtly different question "does Go support this particular type of dynamic dispatch". The second answer even says that "Go ... interfaces are its only form of polymorphism". Runtime polymorphism is a form of dynamic dispatch! (The only form I know to be honest but I don't claim to be an expert and don't have your experience of lisp-like languages.) The first answer talks about inheritence but never mentions dynamic dispatch at all. If you reduce the whole question down to two totally separate structs (none of that weird Go inheritence / composition stuff) with only one method each, both implementing the same interface, and you called the method through the interface, then that would be dynamic dispatch. Of course, it's not the dynamic dispatch the question poster wanted. And it's not inheritence (although I think that term is much more ambiguous but I still wouldn't dispute it).
- jonathanstrange 3y ago
  Fair enough, there is no doubt you can have some sort of dynamic dispatch without inheritance. I'm more skeptical about your definition of OOP. That seems silly from a historical perspective, and they really shouldn't have taught you that at university. Historically, dynamic dispatch was invented and used for full-fledged OOP systems, so much that you'd expect from the feature "dynamic dispatch" the ability to determine an object's class at runtime and dispatch methods based on it. Smalltalk is a good example, it has full support for inheritance and exactly the kind of dynamic dispatch I described, like practically every other OOP language that has ever been invented. They merely differ in whether they allow single dynamic dispatch or have multiple dynamic dispatch like e.g. CLOS. As far as I know, Go's crippled version of structure composition without inheritance is fairly new, and, as much as I like Go, is a rather annoying and artificial limitation. Even modern Pascal has full OOP.

quietbritishjim 3y ago

I suppose we've got bogged down in semantics here (in fairness that's the point of the original article). I agree that Go is not a good language for OO and that's fine because it's not meant to be. But definitions aren't really a matter of opinion. If it's my opinion that apples count as a variety of orange, then that doesn't make me right. Instead, they're defined by what is widely understood by that term. I'm not saying what I've written is authoritative but it was what I was taught at university by someone who was around and academically active when OO languages were being invented (that course had a lot of SmallTalk D-: ) and certainly is a much closer match to how I've usually seen it used since compared to yours. BTW I'm primarily a C++ (and Python and C#) developer, I hardly know Go, so I have no axe to grind here. > Dynamic dispatch means that superclass and subclass methods can be called at runtime depending on what is needed. No it doesn't: it doesn't require the notion of superclass and subclass. Using an interface to call a method still counts as dynamic dispatch. > Here is an explanation of the difference: [1] The thing is, the question asks "does Go support dynamic dispatch" but the answers are about the subtly different question "does Go support this particular type of dynamic dispatch". The second answer even says that "Go ... interfaces are its only form of polymorphism". Runtime polymorphism is a form of dynamic dispatch! (The only form I know to be honest but I don't claim to be an expert and don't have your experience of lisp-like languages.) The first answer talks about inheritence but never mentions dynamic dispatch at all. If you reduce the whole question down to two totally separate structs (none of that weird Go inheritence / composition stuff) with only one method each, both implementing the same interface, and you called the method through the interface, then that would be dynamic dispatch. Of course, it's not the dynamic dispatch the question poster wanted. And it's not inheritence (although I think that term is much more ambiguous but I still wouldn't dispute it).

jonathanstrange 3y ago
Fair enough, there is no doubt you can have some sort of dynamic dispatch without inheritance. I'm more skeptical about your definition of OOP. That seems silly from a historical perspective, and they really shouldn't have taught you that at university. Historically, dynamic dispatch was invented and used for full-fledged OOP systems, so much that you'd expect from the feature "dynamic dispatch" the ability to determine an object's class at runtime and dispatch methods based on it. Smalltalk is a good example, it has full support for inheritance and exactly the kind of dynamic dispatch I described, like practically every other OOP language that has ever been invented. They merely differ in whether they allow single dynamic dispatch or have multiple dynamic dispatch like e.g. CLOS. As far as I know, Go's crippled version of structure composition without inheritance is fairly new, and, as much as I like Go, is a rather annoying and artificial limitation. Even modern Pascal has full OOP.