3 ms·

> Go discourages classical inheritance, Go makes classic inheritance impossible, it is a bit more than discouraging it.

by aikah 10y ago

catnaroek 10y ago
Go might not provide built-in support for classical inheritance, but that doesn't prevent you from rolling your own: (0) Embed base structs. (1) Implement non-overridden methods as redirected calls to base struct methods. (2) Implement overridden method calls however you wish. What Go doesn't make possible is tying inheritance to subtyping, like Java and C++ do. And this is a very good thing.
- aikah 10y ago
  > Go might not provide built-in support for classical inheritance, but that doesn't prevent you from rolling your own: What you described is not inheritance. If you pass your "inherited" type to a function that expect the "parent" type it will not compile. There is no inheritance in Go, and you cannot roll you own. > What Go doesn't make possible is tying inheritance to subtyping There is no subtying whatsoever in Go to begin with. There is no point in "inheritance" if it is not polymorphic. What you just did is create a new type. that is not inheritance in a statically typed language.
  - catnaroek 10y ago
    > What you described is not inheritance. If you pass your "inherited" type to a function that expect the "parent" type it will not compile. That is called “subtyping”, not “inheritance”. Java and C++ happen to conflate the two concepts, but it's perfectly possible to keep them separate. > There is no subtying whatsoever in Go to begin with. A struct is a subtype of every interface its methods are compatible with.
    - aikah 10y ago
      It doesn't really matter. Your suggestion is worthless in practice with Go since "your subtype" doesn't enable polymorphism. you can't pass your "subtype" to a function that expect the parent type. You can absolutely pass a sub class in place of a class in a method expecting the class in Java. See the difference ? what you suggested makes absolutely no sense in Go. That's not even subtyping, you just created another struct type with composition.
      - catnaroek 10y ago
        > It doesn't really matter. Your suggestion is worthless in practice with Go since "your subtype" doesn't enable polymorphism. I never said that struct embedding creates a subtype. I said that it can be used to emulate inheritance (subclassing). Inheritance and subtyping are very different things, and the fact languages like Java and C++ conflate them actually creates several problems. See: [0] http://www.cs.utexas.edu/~wcook/papers/InheritanceSubtyping90/CookPOPL90.pdf http://www.cs.utexas.edu/~wcook/papers/InheritanceSubtyping9... [1] http://stackoverflow.com/a/23592298/46571 http://stackoverflow.com/a/23592298/46571

> Go discourages classical inheritance, Go makes classic inheritance impossible, it is a bit more than discouraging it.

by aikah 10y ago

> Go discourages classical inheritance, Go makes classic inheritance impossible, it is a bit more than discouraging it.

Go might not provide built-in support for classical inheritance, but that doesn't prevent you from rolling your own: (0) Embed base structs. (1) Implement non-overridden methods as redirected calls to base struct methods. (2) Implement overridden method calls however you wish. What Go doesn't make possible is tying inheritance to subtyping, like Java and C++ do. And this is a very good thing.

aikah 10y ago
> Go might not provide built-in support for classical inheritance, but that doesn't prevent you from rolling your own: What you described is not inheritance. If you pass your "inherited" type to a function that expect the "parent" type it will not compile. There is no inheritance in Go, and you cannot roll you own. > What Go doesn't make possible is tying inheritance to subtyping There is no subtying whatsoever in Go to begin with. There is no point in "inheritance" if it is not polymorphic. What you just did is create a new type. that is not inheritance in a statically typed language.
- catnaroek 10y ago
  > What you described is not inheritance. If you pass your "inherited" type to a function that expect the "parent" type it will not compile. That is called “subtyping”, not “inheritance”. Java and C++ happen to conflate the two concepts, but it's perfectly possible to keep them separate. > There is no subtying whatsoever in Go to begin with. A struct is a subtype of every interface its methods are compatible with.
  - aikah 10y ago
    It doesn't really matter. Your suggestion is worthless in practice with Go since "your subtype" doesn't enable polymorphism. you can't pass your "subtype" to a function that expect the parent type. You can absolutely pass a sub class in place of a class in a method expecting the class in Java. See the difference ? what you suggested makes absolutely no sense in Go. That's not even subtyping, you just created another struct type with composition.
    - catnaroek 10y ago
      > It doesn't really matter. Your suggestion is worthless in practice with Go since "your subtype" doesn't enable polymorphism. I never said that struct embedding creates a subtype. I said that it can be used to emulate inheritance (subclassing). Inheritance and subtyping are very different things, and the fact languages like Java and C++ conflate them actually creates several problems. See: [0] http://www.cs.utexas.edu/~wcook/papers/InheritanceSubtyping90/CookPOPL90.pdf http://www.cs.utexas.edu/~wcook/papers/InheritanceSubtyping9... [1] http://stackoverflow.com/a/23592298/46571 http://stackoverflow.com/a/23592298/46571