5 ms·

Interfaces do not provide inheritance either. A language without inheritance in my opinion isn't OOP. Otherwise, you can call C an OOP language, too, because yo

Interfaces do not provide inheritance either. A language without inheritance in my opinion isn't OOP. Otherwise, you can call C an OOP language, too, because you can write C programs in OOP style. Some people do that but it's not a reasonable way to define OOP. Structure composition is not inheritance. I personally wished Go had full OOP, ideally with multiple dispatch. It's what I miss most from CommonLisp and Racket when I write Go. The only arguments against it I've seen so far were rather silly and patronizing arguments along the lines of "we have to protect the programmers."

quietbritishjim 3y ago
A language is OO if it supports two things: * Encapsulation: Bundling data and functions syntactically together (in which case they're commonly called classes and methods) * Dynamic dispatch: Calling a method may call a different function implementation depending on the runtime type of the class instance But that's it. C++ inheritence is actually two features (at least), which you seem to be conflating: it supports dynamic dispatch through virtual methods, but also allows using the implementation of base class methods in derived classes (whether virtual or not). But only the first part is actually needed to be called object oriented. Even VBA is technically OO because its use of COM interfaces allows dynamic dispatch - even though it doesn't support inheriting method implementations at all. (A couple of notes: If a language only supports encapsulation but not dynamic dispatch then it's "object based" rather than object oriented. And, when encapsulation is supported, the language usually also supports data hiding (that's public/protected/private in C++ speak) but technically that's a separate thing.
- jonathanstrange 3y ago
  > 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

A language is OO if it supports two things: * Encapsulation: Bundling data and functions syntactically together (in which case they're commonly called classes and methods) * Dynamic dispatch: Calling a method may call a different function implementation depending on the runtime type of the class instance But that's it. C++ inheritence is actually two features (at least), which you seem to be conflating: it supports dynamic dispatch through virtual methods, but also allows using the implementation of base class methods in derived classes (whether virtual or not). But only the first part is actually needed to be called object oriented. Even VBA is technically OO because its use of COM interfaces allows dynamic dispatch - even though it doesn't support inheriting method implementations at all. (A couple of notes: If a language only supports encapsulation but not dynamic dispatch then it's "object based" rather than object oriented. And, when encapsulation is supported, the language usually also supports data hiding (that's public/protected/private in C++ speak) but technically that's a separate thing.

jonathanstrange 3y ago
> 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.