5 ms·
I don't think you can call a language object-oriented if it doesn't support some form of inheritance and dynamic dispatch. And for Golang that's simply not the
by ThePhysicist 3y ago
I don't think you can call a language object-oriented if it doesn't support some form of inheritance and dynamic dispatch. And for Golang that's simply not the case. You can embed data structures into other structures but the main difference to e.g. C++ is that you don't have proper RTTI (run-time type information) that would do a dynamic dispatch of struct methods, so you can't do anything interesting (i.e. you can embed an "Animal" struct in a "Dog" struct but if you define the ".MakeNoise()" method on the Animal struct and have that call a ".myNoise()" method on the struct to e.g. produce "Woof" or "Meow" then even if you override ".myNoise()" in the "Dog" struct the "Animal" struct will still call its own ".myNoise()" method, as there's no dynamic call table like in C++). People will probably say that's by design but I'd then argue again that's not object-orientation as you can do these things with C structs as well and no one would call C an object-oriented language.
- orwin 3y agoI think traits are a big improvement on inheritance, do you count those as as some form of inheritance? In this case I can agree with you. Personally, when I have to use it, I make abstract classes or better, interfaces. I avoid direct inheritance like the plague. But I've worked on personalized Jenkins where I had to inherit classes from weird modules, so maybe I got burned and my experience isn't the average experience (also, I hate Java now).
- ThePhysicist 3y agoIn my understanding traits (I guess you mean as defined in Rust?) are more powerful than interfaces in the sense that you can define them for objects from the outside, but I don't see how you could use them to build dynamic-dispatch like functionality? Not an expert on traits at all though. I think traits and interfaces are more supportive of a composition-like programming style, one might call that object-oriented but I still think it misses several key concepts of classical object-oriented languages.
- bheadmaster 3y agoIn Go, interfaces are used for dynamic dispatch. No need to the the whole ".MakeNoise() calls .myNoise()" dance, just implement ".MakeNoise()" on each type directly: type Animal interface { MakeNoise() } type Dog struct{} func (Dog) MakeNoise() { fmt.Println("Woof!") } type Cat struct{} func (Cat) MakeNoise() { fmt.Println("Meow.") } func MakeNoises(as ...Animal) { for _, a := range as { a.MakeNoise() } } func main() { d := Dog{} c := Cat{} MakeNoises(d, c) }
- ThePhysicist 3y agoThat's not what I described above. Object-orientation means that you can override behavior of a base class in a derived class and have the base class be "aware" of that overridden functionality at runtime. You could probably argue that interfaces allow composition and thereby an object-oriented style, I don't think that's what most people would understand as object-oriented programming, though.
- bheadmaster 3y ago> Object-orientation means that you can override behavior of a base class in a derived class while maintaining base functionality, and have the base class be "aware" of that overridden functionality at runtime. No, that's not an inherent property of OOP, that's a property of C++. To be OOP, you must support inheritance (which Go does, through struct embedding) and polymorphism (which Go also does, through interfaces). The polymorphic inheritance you're talking about is strictly a C++-specific implementation detail.
- ThePhysicist 3y agoStruct embedding is simple composition, not inheritance. If you embed an "Animal" in a "Dog" struct, the "Animal" struct doesn't have any means to find out it's a "Dog", i.e. it can never find out at runtime that it's embedded in a "Dog" object or rely on functionality defined in the "Dog" object (unless you write specific helper functionality for that). You can do Golang-style composition via union structs in C as well, but that doesn't make C an object-oriented language. Of course you can build a vtable in C or Golang to make object-orientation work (C++ came to being like that), but again it's not a concept the language itself supports.
- hannofcart 3y agoMaybe am missing some nuance in the above comment, but can't the above be achieved in Go with an interface: type Animal interface { MakeNoise() } Link to an implementation of scenario: https://go.dev/play/p/bSAFr9i4ex3 https://go.dev/play/p/bSAFr9i4ex3
- ThePhysicist 3y agoSee above, interfaces won't solve that problem unfortunately.
- Fire-Dragon-DoL 3y agoInheritance has nothing to do with oop, oop was about message passing. Most big oop languages seem to discourage inheritance in favor of composition, how can inheritance be a requirement? On the other side, message passing and dynamic dispatch are strictly related and you can do that with golang interfaces! So yes, it does support full oop, what it doesn't support is class-based programming. Does it matter at this point? Oop hasn't solved any of the big problems it claimed and fp did not either. https://news.ycombinator.com/item?id=11966570 https://news.ycombinator.com/item?id=11966570 https://en.wikipedia.org/wiki/Object-oriented_programming?wprov=sfla1 https://en.wikipedia.org/wiki/Object-oriented_programming?wp...
- kaba0 3y agoThat’s just the Alan Kay definition - just because he coined the term, it is not at all how it is used nowadays. OOP as commonly understood requires some form of inheritance.
- Fire-Dragon-DoL 3y agoI don't agree on this statement: the wikipedia page for oop strictly distinguish between the two, given how widespread wikipedia is, that can be considered a valid source for this definition. That page distinguishes between oop and class-based programming