3 ms·
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 exac
by 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 agoI 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 agoInheritance is implicit delegation, in any language. The "implicit" is what makes it inheritance.
- codygman 14y agoI 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.