From the article structs in Go, we know that a struct type can have many fields. Each field is composed of one field name and one field type. In fact, sometimes, a struct field can be composed of one field type only. The way to declare struct fields is called type embedding.
This article will explain the purpose of type embedding and all kinds of details in type embedding.
package main
import "net/http"
func main() {
type P = *bool
type M = map[int]int
var x struct {
string // a defined non-pointer type
error // a defined interface type
*int // a non-defined pointer type
P // an alias of a non-defined pointer type
M // an alias of a non-defined type
http.Header // a defined map type
}
x.string = "Go"
x.error = nil
x.int = new(int)
x.P = new(bool)
x.M = make(M)
x.Header = http.Header{}
}
In the above example, six types are embedded in the struct type. Each type embedding forms an embedded field.
Embedded fields are also called as anonymous fields.
However, each embedded field has a name specified implicitly.
The unqualified type name
of an embedded field acts as the name of the field.
For example, the names of the six embedded fields in the above examples are
string
, error
, int
, P
, M
,
and Header
, respectively.
An embedded field must be specified as a type nameT
or as a pointer to a non-interface type name*T
, andT
itself may not be a pointer type.
The above description is accurate before Go 1.09.
However, with the introduction of type aliases in Go 1.09,
the description becomes a little outdated and inaccurate.
For example, the description doesn't include the case of
the P
field in the example in the last section.
T
can be embedded as an embedded field
unless T
denotes a pointer type which base type
is either a pointer or an interface type.
*T
, where T
is a type name denoting
the base type of the pointer type, can be embedded as an embedded field
only if T
doesn't denote a pointer or interface type.
T
or *T
,
where T is a type name and the embedded type may not
be a pointer type whose base type is a pointer or interface type.
The following lists some example types which can and can't be embedded:
type Encoder interface {Encode([]byte) []byte}
type Person struct {name string; age int}
type Alias = struct {name string; age int}
type AliasPtr = *struct {name string; age int}
type IntPtr *int
type AliasPP = *IntPtr
// These types and aliases can be embedded.
Encoder
Person
*Person
Alias
*Alias
AliasPtr
int
*int
// These types and aliases can't be embedded.
AliasPP // base type is a pointer type
*Encoder // base type is an interface type
*AliasPtr // base type is a pointer type
IntPtr // defined pointer type
*IntPtr // base type is a pointer type
*chan int // base type is a non-defined type
struct {age int} // non-defined non-pointer type
map[string]int // non-defined non-pointer type
[]int64 // non-defined non-pointer type
func() // non-defined non-pointer type
No two fields are allowed to have the same name in a struct,
there are no exceptions for anonymous struct fields.
By the embedded field naming rules,
a non-defined pointer type can't be embedded along with its base type
in the same struct type.
For example, int
and *int
can't be embedded in the same struct type.
A struct type can't embed itself or its aliases, recursively.
Generally, it is only meaningful to embed types who have fields or methods (the following sections will explain why), though some types without any field and method can also be embedded.
The main purpose of type embedding is to extend the functionalities of the embedded types into the embedding type, so that we don't need to re-implement the functionalities of the embedded types for the embedding type.
Many other object-oriented programming languages use inheritance to achieve the same goal of type embedding. Both mechanisms have their own benefits and drawbacks. Here, this article will not discuss which one is better. We should just know Go chose the type embedding mechanism, and there is a big difference between the two:T
inherits another type,
then type T
obtains the abilities of the other type.
At the same time, each value of type T
can also be
viewed as a value of the other type.
T
embeds another type,
then type other type becomes a part of type T
,
and type T
obtains the abilities of the other type,
but none values of type T
can be viewed as values of the other type.
package main
import "fmt"
type Person struct {
Name string
Age int
}
func (p Person) PrintName() {
fmt.Println("Name:", p.Name)
}
func (p *Person) SetAge(age int) {
p.Age = age
}
type Singer struct {
Person // extends Person by embedding it
works []string
}
func main() {
var gaga = Singer{Person: Person{"Gaga", 30}}
gaga.PrintName() // Name: Gaga
gaga.Name = "Lady Gaga"
(&gaga).SetAge(31)
(&gaga).PrintName() // Name: Lady Gaga
fmt.Println(gaga.Age) // 31
}
From the above example, it looks that, after embedding type Person
,
the type Singer
obtains all methods and fields of type Person
,
and type *Singer
obtains all methods of type *Person
.
Are the conclusions right? The following sections will answer this question.
Singer
value is not a Person
value,
the following code doesn't compile:
var gaga = Singer{}
var _ Person = gaga
Singer
and the methods of type *Singer
used in the last example by using the reflection
functionalities provided in the reflect
standard package.
package main
import (
"fmt"
"reflect"
)
... // the types declared in the last example
func main() {
t := reflect.TypeOf(Singer{}) // the Singer type
fmt.Println(t, "has", t.NumField(), "fields:")
for i := 0; i < t.NumField(); i++ {
fmt.Print(" field#", i, ": ", t.Field(i).Name, "\n")
}
fmt.Println(t, "has", t.NumMethod(), "methods:")
for i := 0; i < t.NumMethod(); i++ {
fmt.Print(" method#", i, ": ", t.Method(i).Name, "\n")
}
pt := reflect.TypeOf(&Singer{}) // the *Singer type
fmt.Println(pt, "has", pt.NumMethod(), "methods:")
for i := 0; i < pt.NumMethod(); i++ {
fmt.Print(" method#", i, ": ", pt.Method(i).Name, "\n")
}
}
The result:
main.Singer has 2 fields:
field#0: Person
field#1: works
main.Singer has 1 methods:
method#0: PrintName
*main.Singer has 2 methods:
method#0: PrintName
method#1: SetAge
From the result, we know that the type Singer
really owns
a PrintName
method, and the type *Singer
really
owns two methods, PrintName
and SetAge
.
But the type Singer
doesn't own a Name
field.
Then why is the selector expression gaga.Name
legal for a Singer
value gaga
?
Please read the next section to get the reason.
From the articles structs in Go and
methods in Go, we have learned that,
for a value x
, x.y
is called a selector,
where y
is either a field name or a method name.
If y
is a field name,
then x
must be a struct value or a struct pointer value.
A selector is an expression, which represents a value.
If the selector x.y
denotes a field, it may also
has its own fields (if x.y
is a struct value) and methods.
Such as x.y.z
,
where z
can also be either a field name or a method name.
In Go, (without considering selector colliding and shadowing explained in a later section), if a middle name in a selector corresponds to an embedded field, then that name can be omitted from the selector. This is why embedded fields are also called anonymous fields.
package main
type A struct {
x int
}
func (a A) MethodA() {}
type B struct {
A
}
type C struct {
B
}
func main() {
var c C
// The following 4 lines are equivalent.
_ = c.B.A.x
_ = c.B.x
_ = c.A.x
_ = c.x // x is called a promoted field of type C
// The following 4 lines are equivalent.
c.B.A.MethodA()
c.B.MethodA()
c.A.MethodA()
c.MethodA()
}
This is why the expression gaga.Name
is legal
in the example in the last section.
For it is just the shorthand of gaga.Person.Name
.
Name
is called a promoted field of type Singer
.
func main() {
var c C
pc = &c
// The following 4 lines are equivalent.
fmt.Println(pc.B.A.x)
fmt.Println(pc.B.x)
fmt.Println(pc.A.x)
fmt.Println(pc.x)
// The following 4 lines are equivalent.
pc.B.A.MethodA()
pc.B.MethodA()
pc.A.MethodA()
pc.MethodA()
}
Similarly, the selector gaga.PrintName
can be viewed as
a shorthand of gaga.Person.PrintName
.
But, it is also okay if we think it is not a shorthand.
After all, the type Singer
really has a PrintName
method, though the method is declared implicitly
(please read the section after next for details).
For the similar reason, the selector (&gaga).PrintName
and (&gaga).SetAge
can also be viewed as, or not as,
shorthands of (&gaga.Person).PrintName
and
(&gaga.Person).SetAge
.
Note, we can also use the selector gaga.SetAge
, only if
gaga
is an addressable value of type Singer
.
It is just syntactical sugar of (&gaga).SetAge
.
Please read method calls for details.
In the above examples, c.B.A.x
is called the full form
of selectors c.x
, c.B.x
and c.A.x
.
Similarly, c.B.A.MethodA
is called the full form of selectors
c.MethodA
, c.B.MethodA
and c.A.MethodA
.
If every middle name in the full form of a selector corresponds to
an embedded field, then the number of middle names in the selector
is called the depth of the selector.
For example, the depth of the selector c.MethodA
used
in an above example is 2, for the full form of the selector is
c.B.A.MethodA
.
x
(we should always assume it is addressable, even if it is not),
it is possible that many of its full-form
selectors have the same last item y
and every middle name of these selectors represents an embedded field.
For such cases,
x.y
.
In other words, x.y
denotes the full-form selector with the shallowest depth.
Other full-form selectors are shadowed by the one with the shallowest depth.
x.y
.
We say those full-form selectors with the shallowest depth are colliding with each other.
If a method selector is shadowed by another method selector, and the two corresponding method signatures are identical, we say the first method is overridden by the other one.
For example, assumeA
, B
and C
are three defined types.
type A struct {
x string
}
func (A) y(int) bool {
return false
}
type B struct {
y bool
}
func (B) x(string) {}
type C struct {
B
}
The following code doesn't compile.
The reasons is selector v1.A.x
collides with v1.B.x
collide with each other,
so both of them can't be shortened to v1.x
.
The same situation is for selector v1.A.y
and v1.B.y
.
var v1 struct {
A
B
}
func f1() {
_ = v1.x
_ = v1.y
}
The following code compiles okay. The selector
v2.C.B.x
is shadowed by v2.A.x
, so the
selector v2.x
is a shortened form of v2.A.x
actually.
For the same reason, the selector v2.y
is a shortened form of
v2.A.y
, not of v2.C.B.y
.
var v2 struct {
A
C
}
func f2() {
fmt.Printf("%T \n", v2.x) // string
fmt.Printf("%T \n", v2.y) // func(int) bool
}
As mentioned above, both of type Singer
and
type *Singer
have a PrintName
method each,
and the type *Singer
also has a SetAge
method.
However, we never explicitly declare these methods
for the two types. Where do these methods come from?
S
embeds a type T
and the embedding is legal,
T
,
if the selectors to that method neither collide with nor are shadowed
by other selectors, then compilers will implicitly declare
a corresponding method with the same prototype
for the embedding struct type S
.
And consequently, compilers will also
implicitly declare
a corresponding method for the pointer type *S
.
*T
,
if the selectors to that method neither collide with nor are shadowed
by other selectors, then compilers will implicitly declare
a corresponding method with the same prototype for the pointer type *S
.
The above facts still hold true even if *T
is not embeddable
(a.k.a, T
is a pointer or interface type),
in which cases, the method set of *T
is blank.
struct{T}
and type *struct{T}
both obtain all the methods of the type denoted by T
.
*struct{T}
, type struct{*T}
,
and type *struct{*T}
obtains all the methods of type *T
.
Singer
and type *Singer
.
func (s Singer) PrintName() {
s.Person.PrintName()
}
func (s *Singer) PrintName() {
(*s).Person.PrintName()
}
func (s *Singer) SetAge(age int) {
// <=> (&((*s).Person)).SetAge(age)
(&s.Person).SetAge(age)
}
From the article methods in Go, we know that we can't explicitly declare methods for non-defined struct types and non-defined pointer types whose base types are non-defined struct types. But through type embedding, such non-defined types can also own methods.
Here is another example to show which implicit methods are declared.package main
import "fmt"
import "reflect"
type F func(int) bool
func (f F) Validate(n int) bool {
return f(n)
}
func (f *F) Modify(f2 F) {
*f = f2
}
type B bool
func (b B) IsTrue() bool {
return bool(b)
}
func (pb *B) Invert() {
*pb = !*pb
}
type I interface {
Load()
Save()
}
func PrintTypeMethods(t reflect.Type) {
fmt.Println(t, "has", t.NumMethod(), "methods:")
for i := 0; i < t.NumMethod(); i++ {
fmt.Print(" method#", i, ": ",
t.Method(i).Name, "\n")
}
}
func main() {
var s struct {
F
*B
I
}
PrintTypeMethods(reflect.TypeOf(s))
fmt.Println()
PrintTypeMethods(reflect.TypeOf(&s))
}
The result:
struct { main.F; *main.B; main.I } has 5 methods:
method#0: Invert
method#1: IsTrue
method#2: Load
method#3: Save
method#4: Validate
*struct { main.F; *main.B; main.I } has 6 methods:
method#0: Invert
method#1: IsTrue
method#2: Load
method#3: Modify
method#4: Save
method#5: Validate
If a struct type embeds a type which implements an interface type
(the embedded type may be the interface type itself),
then generally the struct type also implements the interface type,
exception there is a method specified by the interface type
shadowed by or colliding other methods or fields.
For example, in the above example program, both the embedding struct type and
the pointer type whose base type is the embedding struct type implement the interface type I
.
Age
has no methods, for it doesn't embed any types.
X
has two methods, IsOdd
and Double
.
IsOdd
is obtained through embedding type MyInt
.
Y
has no methods, for its embedded type Age
has not methods.
Z
has only one method, IsOdd
,
which is obtained through embedding type MyInt
.
It doesn't obtain the method Double
from type X
,
for it doesn't embed type X
.
type MyInt int
func (mi MyInt) IsOdd() bool {
return mi%2 == 1
}
type Age MyInt
type X struct {
MyInt
}
func (x X) Double() MyInt {
return x.MyInt + x.MyInt
}
type Y struct {
Age
}
type Z X
Not only can struct types embed other types, but also can interface types. But interface types can only embed interface types. Please read interfaces in Go for details.
package main
type I interface {
m()
}
type T struct {
I
}
func main() {
var t T
var i = &t
t.I = i
i.m() // will call t.m(), then call i.m() again, ...
}