3 ms·

So, according to this logic, even C is Object-oriented with support for inheritance, because: struct SubClass { struct SuperClass super; /

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 13y 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 13y 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?
  - voidlogic 13y ago
    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.
    - shared4you 13y ago
      Ah sorry, I have no idea about Java or final, so ... can't comment.
      - voidlogic 13y ago
        http://en.wikipedia.org/wiki/Final_%28Java%29#Final_methods http://en.wikipedia.org/wiki/Final_%28Java%29#Final_methods
Evbn 13y ago
Go try calling SuperClass's method on Subclass, and tell us the two problems you face.
mdwrigh2 13y ago
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.

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 13y 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 13y 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?
- voidlogic 13y ago
  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.
  - shared4you 13y ago
    Ah sorry, I have no idea about Java or final, so ... can't comment.
    - voidlogic 13y ago
      http://en.wikipedia.org/wiki/Final_%28Java%29#Final_methods http://en.wikipedia.org/wiki/Final_%28Java%29#Final_methods

Evbn 13y ago

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

mdwrigh2 13y ago

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.