Comment by cgcardona | Hacker News Reader

Comment by cgcardona | Hacker News Reader

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&...

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-...

Here are examples of inheritance in Go: http://golangtutorials.blogspot.com/2011/06/inheritance-and-... http://diveintogo.blogspot.com/2010/03/classic-inheritance-i...

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.

Inheritance is implicit delegation, in any language. The "implicit" is what makes it inheritance.

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.

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.

It does have inheritance although the syntax is different:

  type SubClass struct {
    SuperClass
    other fields...
  }

Embedding is not strictly the same thing as inheritance.

That is not inheritance, it is embedding: http://golang.org/doc/effective_go.html#embedding

So, according to this logic, even C is Object-oriented with support for inheritance, because:

     struct SubClass {
        struct SuperClass super;
        // .. other fields ...
     }

is valid.

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_

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?

You mean like final in Java? I don't believe there is. Go has a different way of handling OO and so far I have never needed "final". In Go embedding is not common and interfaces are used much more.

In Go, having final in an embedded struct affect the containing struct seems wrong IMHO- this would allow embeded fields to dictate the behaviour of things that embed them. I don't think most programmers would be happy with adding a field to a struct and as a consequence be prevented from implementing a given method signature.

Ah sorry, I have no idea about Java or final, so ... can't comment.

http://en.wikipedia.org/wiki/Final_%28Java%29#Final_methods

Go try calling SuperClass's method on Subclass, and tell us the two problems you face.

I don't think you really understood the Go example. In C if I have:

    struct SuperClass {
        int foo;
    };
    struct SubClass {
        struct SuperClass super;
    };

Then to set the foo item I'd have to do: struct SubClass bar; bar.super.foo = 5;

Whereas in Go I could say: type SuperClass struct { foo int } type SubClass struct { SuperClass } bar := SubClass{} bar.foo = 5

So, small difference, but I think valid.

Reply on news.ycombinator.com