4 ms·

The most suprising part to me is that it doesn't support inheritance. I'm currently reading 'Object Oriented Design with Applications' by Grady Booch [1] and I

The most suprising part to me is that it doesn't support inheritance. I'm currently reading 'Object Oriented Design with Applications' by Grady Booch [1] and I noticed the following in the section 'Object Oriented Programming' > …object-oriented programming (1) uses objects, not algorithms, as its fundamental logical building blocks; (2) each object is an instance of some class; and (3) classes are related to one another via inheritance relationships. > …By this definition, some languages are object-oriented, and some are not. Stroustrup suggests that "if the term 'object-oriented language' means anything, it must mean a language that has mechanisms that support the object-oriented style of programming well. A language supports a programming style well if it provides facilities that make it convenient to use that style. A language does not support a technique if it takes exceptional effort or skill to write such programs; in that case, the language merely enables programmers to use the techniques" >…if a language does not provide direct support for inheritance, then it is not object-oriented. Cardelli and Wegner distinguish such languages by calling them object-based rather than object-oriented. Per this definition I wonder if Go might not be better labeled 'object-based.' [1] http://www.amazon.com/gp/search?index=books&linkCode=qs&keywords=0805300910 http://www.amazon.com/gp/search?index=books&linkCode=qs&...

codygman 14y ago
Define "direct support" for inheritance. IMO, a symbol named inherit doesn't have to exist for there to be inheritance. Here is a blog post answering your exact questions: http://areyoufuckingcoding.me/2012/07/25/object-desoriented-language/ http://areyoufuckingcoding.me/2012/07/25/object-desoriented-... Here are examples of inheritance in Go: http://golangtutorials.blogspot.com/2011/06/inheritance-and-subclassing-in-go-or.html http://golangtutorials.blogspot.com/2011/06/inheritance-and-... http://diveintogo.blogspot.com/2010/03/classic-inheritance-in-go-lang.html http://diveintogo.blogspot.com/2010/03/classic-inheritance-i...
- shared4you 14y ago
  I come from C++ background, so by "direct support", I think he means a language construct that clearly shows the inheritance relationship, as in Java: public class MountainBike extends Bicycle or C++: class MountainBike: public Bicycle From those links, it looks like in Go, you use an anonymous struct inside a normal class. I would call it "aggregation" or "containment" (or implicit delegation), not inheritance. It suggests "has-a" relationship rather than an "is-a" relationship. The Go's "syntax" for inheritance (if you can call that) is ambiguous, unlike C++ or Java.
  - Evbn 14y ago
    Inheritance is implicit delegation, in any language. The "implicit" is what makes it inheritance.
  - codygman 14y ago
    I don't see any downsides to this though, could you enumerate any you can think of? For instance, I believe I an model relationships either way and accomplish the same thing with little to no difference.
koalaman 14y ago
FWIW, I think that removing inheritance is a major strength of Go. Interfaces and composition give you most or all of what you want and get you in a lot less trouble.
zik 14y ago
It does have inheritance although the syntax is different: type SubClass struct { SuperClass other fields... }
- redbad 14y ago
  Embedding is not strictly the same thing as inheritance.
- voidlogic 14y ago
  That is not inheritance, it is embedding: http://golang.org/doc/effective_go.html#embedding http://golang.org/doc/effective_go.html#embedding
- shared4you 14y ago
  So, according to this logic, even C is Object-oriented with support for inheritance, because: struct SubClass { struct SuperClass super; // .. other fields ... } is valid.
  - voidlogic 14y ago
    So Go has embedding not inheritance because SubClass is not an instance of SuperClass, there is no hierarchy, only composition. BUT what you might not realize is that any method defined on SuperClass (and only defined on SuperClass) can be called on SubClass, but it operates on SuperClass data. This allows SubClass to use SuperClass to help it fulfil an interface for example. See it in action: http://play.golang.org/p/8kiwu1PlW_ http://play.golang.org/p/8kiwu1PlW_
    - shared4you 14y ago
      This is similar to C++ in which base class methods are 'virtual'. Is there a way to stop this behaviour? Just thinking how non-virtual methods can be implemented then. C++ has a keyword, 'virtual', for switching this behaviour, but any analogue in Go?
      - 14y ago

codygman 14y ago

Define "direct support" for inheritance. IMO, a symbol named inherit doesn't have to exist for there to be inheritance. Here is a blog post answering your exact questions: http://areyoufuckingcoding.me/2012/07/25/object-desoriented-language/ http://areyoufuckingcoding.me/2012/07/25/object-desoriented-... Here are examples of inheritance in Go: http://golangtutorials.blogspot.com/2011/06/inheritance-and-subclassing-in-go-or.html http://golangtutorials.blogspot.com/2011/06/inheritance-and-... http://diveintogo.blogspot.com/2010/03/classic-inheritance-in-go-lang.html http://diveintogo.blogspot.com/2010/03/classic-inheritance-i...

shared4you 14y ago
I come from C++ background, so by "direct support", I think he means a language construct that clearly shows the inheritance relationship, as in Java: public class MountainBike extends Bicycle or C++: class MountainBike: public Bicycle From those links, it looks like in Go, you use an anonymous struct inside a normal class. I would call it "aggregation" or "containment" (or implicit delegation), not inheritance. It suggests "has-a" relationship rather than an "is-a" relationship. The Go's "syntax" for inheritance (if you can call that) is ambiguous, unlike C++ or Java.
- Evbn 14y ago
  Inheritance is implicit delegation, in any language. The "implicit" is what makes it inheritance.
- codygman 14y ago
  I don't see any downsides to this though, could you enumerate any you can think of? For instance, I believe I an model relationships either way and accomplish the same thing with little to no difference.

koalaman 14y ago

FWIW, I think that removing inheritance is a major strength of Go. Interfaces and composition give you most or all of what you want and get you in a lot less trouble.

zik 14y ago

It does have inheritance although the syntax is different: type SubClass struct { SuperClass other fields... }

redbad 14y ago
Embedding is not strictly the same thing as inheritance.
voidlogic 14y ago
That is not inheritance, it is embedding: http://golang.org/doc/effective_go.html#embedding http://golang.org/doc/effective_go.html#embedding
shared4you 14y ago
So, according to this logic, even C is Object-oriented with support for inheritance, because: struct SubClass { struct SuperClass super; // .. other fields ... } is valid.
- voidlogic 14y ago
  So Go has embedding not inheritance because SubClass is not an instance of SuperClass, there is no hierarchy, only composition. BUT what you might not realize is that any method defined on SuperClass (and only defined on SuperClass) can be called on SubClass, but it operates on SuperClass data. This allows SubClass to use SuperClass to help it fulfil an interface for example. See it in action: http://play.golang.org/p/8kiwu1PlW_ http://play.golang.org/p/8kiwu1PlW_
  - shared4you 14y ago
    This is similar to C++ in which base class methods are 'virtual'. Is there a way to stop this behaviour? Just thinking how non-virtual methods can be implemented then. C++ has a keyword, 'virtual', for switching this behaviour, but any analogue in Go?
    - 14y ago