Different struct paradigm question

<p>Hi,</p> <p>My question is based around this toy example: <a href="https://play.golang.org/p/94bQZK7olb" rel="nofollow">https://play.golang.org/p/94bQZK7olb</a></p> <p>In order for me to be able to change the name inside the v1 struct, I need a pointer instance. However, I can use a value type for v2 and still be able to change the name for the struct.</p> <p>My question is as follows. What is the difference? Any performance benefits? I know that v2 does not satisfy possible interface inheritance.</p> <p>Also as the last question, when should you choose one over the other, if there is any case at all?</p> <p>Thanks!</p> <hr/>**评论：**<br/><br/>TheMerovius: <pre><blockquote> <p>What is the difference?</p> </blockquote> <p>Syntax and probably some runtime overhead. The closure will allocate, so it&#39;s, from a memory-layout perspective, mostly the same, there is an additional indirection when accessing the data. However, as the struct-members could, strictly speaking, change, the compiler can&#39;t inline the calls to SetName and Name, so it might incur an additional performance hit (as always, if you care about that, measure). v2 will also be bigger, if you plan to have lots of them (e.g. in a slice), this will significantly increase the storage requirements and if you have a slice of v1 (instead of *v1), this will be even more significant, because you save the strings more compactly, instead of just saving pointers to a struct which contains the string (as you effectively do with v2).</p> <p>Also, the v2 version is very much unidiomatic. The v1 version too, though - you should use &#34;type Foo struct { Name string }&#34; instead and leave out getters and setters.</p> <blockquote> <p>Also as the last question, when should you choose one over the other, if there is any case at all?</p> </blockquote> <p>You probably should never use v2. The only case, where it&#39;s useful to have a func as a struct-member, is if you want to have user-controlled behavior, e.g. the SplitFunc of bufio.Scanner. If you want to write getters and setters, you shouldn&#39;t do that either - if you have both, then that is probably just a public field.</p></pre>driusan: <pre><p>Function parameters are passed by value, not by reference in Go. <code>func (a SomeType) foo(bar int) { code }</code> is basically syntactic sugar around <code>func foo(a SomeType, bar int) { code }</code>.</p> <p>With that in mind, what do you think the difference is between your two examples?</p></pre>9nut: <pre><p>you can use values of type v1 in places where an interface with a matching method (or method set) is expected. using your example, here is an illustration: <a href="https://play.golang.org/p/9pqbTydv13" rel="nofollow">https://play.golang.org/p/9pqbTydv13</a></p></pre>