Object. SetKey1 (string) does not necessarily change the value of Key1.

Func (O Object)setKey1(value string){
      O.key=value
}

Func (O *Object)setKey1(value string){
      O.key=value
}
Copy the code

The above is just a value copy, yes, really just a value copy. Complete, I wrote the following code:

package main


type ttt1 struct {
	A1 string
}

func (t ttt1)setA1()  {
	t.A1="666"
}

func (t *ttt1)set2A1()  {
	t.A1="777"
}

func main() {
	var t ttt1
	t.set2A1()
	println(t.A1)
	t.setA1()
	println(t.A1)
}

Copy the code

Note: The final output is 777 777, not 777 666

There is also the issue of interface assignment if

interface{
set2A1()
}
Copy the code

So the first Oject is func (o object)set2A1() and the first Oject is func (o object2)set2A1() and the compiler won’t let you write that, because it doesn’t make sense, but one method is value passing and one method is address passing. My last piece of code:

package main

type ttt1 struct {
	A1 string
}

type ttt2 struct {
	A1 string
}

type IN interface {
	set2A1()
}

func (t ttt1) setA1() {
	t.A1 = "666"
}

func (t *ttt1) set2A1() {
	t.A1 = "777"
}

func (t *ttt2) set2A1() {
	t.A1 = "777"
}

func main() {
	var t1 ttt1
	var t2 ttt2
	var i IN
	i = t1
	i.set2A1()
	println(t1.A1)
	i = t2
	i.set2A1()
	println(t2.A1)

}

Copy the code

With Golang’s characteristics, it’s easy to understand why the Pointers are flying. I think it’s just good on the surface! We don’t have to worry about wild Pointers with GC anyway. But, for example, you can study the contents of a library, or you can study previous code. If you have two things crammed into an interface, and there are other functions in those two things, then you can mess around with passing values and references. Interface assignment, I think is really a troublesome thing, their code, it is best to just provide a concise interface exposed. Don’t expect your interface to become a standard, someone else to write two functions and implement your interface.