5 ms·

That'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"

That'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 ago
  Struct 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.
  - deleted 3y ago
    [deleted]
  - bheadmaster 3y ago
    > Struct embedding is simple composition, not inheritance. In C++, composition differs from inheritance because when you embed an object inside another object, you cannot call its method directly, but through a wrapper: class Dog { Animal a; bool IsAlive() { return this->a.IsAlive() } } However, in Go, you can call their methods directly: type Dog struct { Animal } func main() { Dog.IsAlive() } So the distinction itself isn't really meaningful. In Go, composition is inheritance. How else do you define inheritance, if not as ability to call methods of the inherited type? > 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 I'm not quite clear on what you mean. How exactly does this work in C++? How do you "detect" it's a Dog on runtime, or "rely" on functionality defined in Dog? If you can provide code example, that'd make things much easier for me to understand.
    - JonChesterfield 3y ago
      C++ has that syntax under the name "unnamed" or "anonymous" fields. It's trivial syntactic sugar. That's unlikely to be called inheritance though.
    - ThePhysicist 3y ago
      If you redefine OOP as functional composition then almost every language passes as object-oriented, including C. To me that simply doesn't make any sense though, and I don't think it's what people would understand as object-oriented in the context of a programming language. Inheritance is a two-way relationship, i.e. if "Dog" overrides functionality in "Animal" then an internal method defined in "Animal" that calls that functionality would be dispatched to the overridden one defined in "Dog". That simply doesn't happen in Golang, hence it does not implement inheritance. C++ e.g. uses vtables for that.
      - bheadmaster 3y ago
        > Inheritance is a two-way relationship, i.e. if "Dog" overrides functionality in "Animal" then an internal method defined in "Animal" that calls that functionality would be dispatched to the overridden one defined in "Dog". I disagree, I think that's actually bundling the concept of polymorphism with the concept of inheritance. Okay, C++ does it, but is there any other reason why inheritance must support polymorphic methods in order to be "real" inheritance? C++ uses virtual classes to achieve polymorphism through inheritance. Go simply uses interfaces. I don't see any reason why Go's approach would be "less OOP" than C++.
        deleted 3y ago
        [deleted]
    - kaba0 3y ago
      That’s just structural typing..
- noduerme 3y ago
  This is really strange, since pretty much all modern languages bundle structural inheritance and polymorphism together; it's definitely not just a C++ oddity, it's a pretty fundamental aspect of Java, JS, PHP, Python, ... I suppose polymorphic inheritance bundled together isn't a requirement of OO-style coding, but without it you have no concept of scope and without that you really can't say a language itself is Object Oriented.
  - bheadmaster 3y ago
    > it's definitely not just a C++ oddity, it's a pretty fundamental aspect of Java, JS, PHP, Python, ... Yes, but I'd argue that's because all those languages just blindly copied what the massively successful C++ was doing at the time. Nobody gave it a second thought. From the perspective of language capability, polymorphic inheritance doesn't give you anything that you cannot achieve with polymorphism and inheritance alone. In fact, there was no polymorphism outside of virtual methods in C++. If you want polymorphism, you have to implement it through virtual methods, there's just no other way.

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 ago
Struct 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.
- deleted 3y ago
  [deleted]
- bheadmaster 3y ago
  > Struct embedding is simple composition, not inheritance. In C++, composition differs from inheritance because when you embed an object inside another object, you cannot call its method directly, but through a wrapper: class Dog { Animal a; bool IsAlive() { return this->a.IsAlive() } } However, in Go, you can call their methods directly: type Dog struct { Animal } func main() { Dog.IsAlive() } So the distinction itself isn't really meaningful. In Go, composition is inheritance. How else do you define inheritance, if not as ability to call methods of the inherited type? > 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 I'm not quite clear on what you mean. How exactly does this work in C++? How do you "detect" it's a Dog on runtime, or "rely" on functionality defined in Dog? If you can provide code example, that'd make things much easier for me to understand.
  - JonChesterfield 3y ago
    C++ has that syntax under the name "unnamed" or "anonymous" fields. It's trivial syntactic sugar. That's unlikely to be called inheritance though.
  - ThePhysicist 3y ago
    If you redefine OOP as functional composition then almost every language passes as object-oriented, including C. To me that simply doesn't make any sense though, and I don't think it's what people would understand as object-oriented in the context of a programming language. Inheritance is a two-way relationship, i.e. if "Dog" overrides functionality in "Animal" then an internal method defined in "Animal" that calls that functionality would be dispatched to the overridden one defined in "Dog". That simply doesn't happen in Golang, hence it does not implement inheritance. C++ e.g. uses vtables for that.
    - bheadmaster 3y ago
      > Inheritance is a two-way relationship, i.e. if "Dog" overrides functionality in "Animal" then an internal method defined in "Animal" that calls that functionality would be dispatched to the overridden one defined in "Dog". I disagree, I think that's actually bundling the concept of polymorphism with the concept of inheritance. Okay, C++ does it, but is there any other reason why inheritance must support polymorphic methods in order to be "real" inheritance? C++ uses virtual classes to achieve polymorphism through inheritance. Go simply uses interfaces. I don't see any reason why Go's approach would be "less OOP" than C++.
      - deleted 3y ago
        [deleted]
  - kaba0 3y ago
    That’s just structural typing..
noduerme 3y ago
This is really strange, since pretty much all modern languages bundle structural inheritance and polymorphism together; it's definitely not just a C++ oddity, it's a pretty fundamental aspect of Java, JS, PHP, Python, ... I suppose polymorphic inheritance bundled together isn't a requirement of OO-style coding, but without it you have no concept of scope and without that you really can't say a language itself is Object Oriented.
- bheadmaster 3y ago
  > it's definitely not just a C++ oddity, it's a pretty fundamental aspect of Java, JS, PHP, Python, ... Yes, but I'd argue that's because all those languages just blindly copied what the massively successful C++ was doing at the time. Nobody gave it a second thought. From the perspective of language capability, polymorphic inheritance doesn't give you anything that you cannot achieve with polymorphism and inheritance alone. In fact, there was no polymorphism outside of virtual methods in C++. If you want polymorphism, you have to implement it through virtual methods, there's just no other way.