I'm currently playing around with some go code, and have run into a small problem involving embedding which I can't find a satisfactory answer to. Given two types, one of which embeds the other, and which satisfy an interface, I'd like the embedded type to be able to reflect on properties of the embedder in order to provide default responses, so that the object doesn't have to define all the methods in the interface, unless they want to override.
In the toy example below, I would like to be able to define a hello() func on embedded which deals with the default case and just returns Name (NB this is a toy example, the real code is more complex and useful), WITHOUT requiring that the object defines all the methods on the interface explicitly. The real code uses reflection to divine the class name of the object type and construct names, and currently I'm calling base class helpers passing in an instance of the type, but this doesn't feel satisfactory.
package main
type MyInterface interface {
hello() string
//...
}
type Embedded struct {
}
func (e *Embedded) hello() string {
name := "none"
// Would like to be able to return name of object here *if* embedded
// What's the best approach to tackle this?
return name
}
type Object struct {
*Embedded
Name string
}
/*
// Would like an *optional* override, with default being embedded somehow replying with data from Object
func (o *Object) hello() string {
return o.Name
}
*/
func main() {
o := &Object{Name:"My Object Name"}
println("Hello world",o.hello())
}
On goplay:
http://play.golang.org/p/ClOOCef9Zb
I'd be interested to hear of other solutions in Go to this sort of issue (providing default functions which use properties of the embedding class) as well as a solution to this particular problem (if there is one). The only solution I have so far is either:
Require a redefinition of method hello() on all types satisfying this interface, and just give up on having a 'base' class which provides default methods Call embedded helper functions with a pointer to the object instance, so types can have mostly empty methods calling the embedded type.
If there are completely different approaches which would be valuable in Go and do not attempt to replicate the inheritance model I'd be interested to hear about them, so far this is the only time I've missed in inheritance...
A method's receiver is a / refers to an instance of the respective type T. There's no language supported way how to obtain any information about T being embedded in, say U while executing T's method:
type (
T foo
U struct {
t T
f baz
}
)
func bar() {
var t T
var u U
t.foo()
u.t.foo()
}
func (t T) foo() {} // t might be or be not embeded in u
func (t *T) qux() {} // *t might be or be not embeded in u
You're probably trying to use structural inheritance. That's not supported. There is composition of types by embedding, but that's not something analogous to a class hierarchy.
OTOH, Go interfaces support inheritance and method overriding, so that may be the way. Just note that in this case the inheritance is behavioral, not structural.
To tackle this I've decided to ditch the ersatz inheritance, and specify the information the model needs to share in an interface (the lack of automatic attribute accessors for fields here is a little annoying, the object above has to explicitly export these to allow anyone passing a MyInterface ref around to use them, the field Name is public but not accessible even if Name() string is defined on the Interface).
The model then calls helper functions in another package, and supplies itself as a parameter where that is useful, and as it conforms to MyInterface it can be interrogated that way. So it (and other MyInterface objects like it) can have complex operations done using their public information and act as a facade. Obviously in the trivial example above this is pointless but I wanted to share code from a package between several MyInterface types, and will now go with this approach rather than embedding.
So my main takeaway here, as pointed out by jnml above, is that embedding is not useful for mixing in functions that rely on instance state, and is not a straightforward replacement for a base class in an inheritance hierarchy. Obvious perhaps if you have been working with Go for a while...