<p>Hello Gophers!</p>
<p>Recently I've taken to declaring constructors on the structs themselves, like this:</p>
<pre><code>func (StructName) New() *StructName {
return &StructName{}
}
</code></pre>
<p>And creating an object then becomes <code>obj := StructName{}.New()</code>. Obviously there would be some allocation overheads if you'd do this in a very hot loop, but I do prefer the more explicit binding of the constructor to the actual struct. If I would be writing <code>func NewStructName() *StructName</code> it wouldn't give me this explicitness.</p>
<p>I've spotted <code>New</code> being used in packages like <code>google.golang.org/api/youtube/v3</code> and others, and I also find it cool that I get a notation that translates from packages to structures. In some cases, I can also chain the constructor with some one off call, like this <a href="https://play.golang.org/p/Aj1oJDSg-z-" rel="nofollow">go playground</a>.</p>
<p>What do you think, am I missing some really hard pitfall here? Bad idea, yay or nay?</p>
<hr/>**评论：**<br/><br/>shovelpost: <pre><p>Ideally don't use constructors and try to <a href="https://twitter.com/davecheney/status/948058108722536448" rel="nofollow">make the zero</a> <a href="https://www.youtube.com/watch?v=PAAkCSZUG1c&t=6m25s" rel="nofollow">value useful</a>.</p>
<p>If it's not possible then just use constructors as shown in <a href="https://golang.org/doc/effective_go.html#composite_literals" rel="nofollow">Effective Go</a>.</p>
<p>Don't trust the Go code you see in Google's APIs. Most of them are auto generated.</p></pre>titpetric: <pre><p>I agree, the zero value should be useful if possible. The constructor however is there to possibly take some options, like in <a href="https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis" rel="nofollow">this article from Dave Cheney</a>. He also goes on to eliminate a lot of specific constructors in favor of one more general one.</p>
<p>There are many examples of something like Googles APIs in the wild, notably the use of <code>New()</code> in self contained packages, vs. having them scoped on structs where they usually become <code>NewStructName()</code>. The difference here is that if you'd split your structs into packages, you wouldn't worry about function name collisions, and you could have <code>New()</code> in each package. Of course, if you don't want to split them... I guess having a more explicit binding to the struct object sounds good to me, but perhaps not to everyone :)</p>
<p>p.s. yeah, I understood that you'd have to be superhuman to produce 900kb of Go code just in one file for the youtube api. I mean, <em>I did hear stories about Googlers</em>,...</p></pre>shovelpost: <pre><p>There's nothing wrong with having a package level function called <code>New()</code> especially if good package naming makes the intention clear.</p>
<p>Using <code>StructName{}.New()</code> feels clunky and very Java-esque to me but I don't think it has any practical disadvantages. I would argue it's less readable but on this case I think it's subjective.</p></pre>
