<p>In a small project that I am writing, I have a package <code>models</code> that exposes a type <code>Transaction</code>. In another package <code>controllers</code>, I make frequent reference to <code>models.Transaction</code>.</p>
<p>From a a purely software engineering perspective, what would be the advantages and disadvantages of using the new Go 1.9 type alias language feature to alias <code>models.Transaction</code> as <code>Transaction</code> in the <code>controllers</code> package (<code>type Transaction = models.Transaction</code>) so that I don't need to type <code>models.</code> at every reference, setting aside the arguments about how easy it is to type <code>models.Transaction</code> using a modern editor?</p>
<p>I'm not saying that I am going to do this. I just thinking about the implications.</p>
<hr/>**评论：**<br/><br/>ChristophBerger: <pre><p>Maybe it helps if considering the original use case for type aliases: To support <em>gradual code repair</em>, as outlined <a href="https://talks.golang.org/2016/refactor.article" rel="nofollow">here</a>.</p>
<p>The goal is to move a type from one package to another without breaking client code that still refers to the type in the old package. Then, after all client packages have been refactored to refer to the new package only, the alias can be removed and the old package can be retired.</p>
<p>So the original intent was to use type aliases only temporarily during phases of refactoring. (Which IMHO does not exclude any other use that seems justifiable.)</p>
<p>For your use case (of using a type alias permanently as a shortcut to a type in another package), I see two main consequences:</p>
<ul>
<li>Easier to write (as you said, this saves some typing)</li>
<li>But maybe harder to comprehend when reading the code (as the reader loses the mental reference to the <code>models</code> package.)</li>
</ul></pre>skidooer: <pre><p>If it is simply for reducing keystrokes, why type aliases over 'dot' imports? The latter only requires two extra characters per package.</p>
<p>From a software engineering perspective, based on your description, I find myself asking if Transaction is actually a separate concern that warrants a separate package in the first place? To pick a random example from the standard library, the <code>http.Client</code> type is controller-like and the <code>http.Request</code> type is model-like, but they live in the same package as they are of the same concern.</p>
<p>I would suggest that if you have good reason to think of these as a separate concerns, I think it warrants letting the reader of your code explicitly see it as a separate concern. Aliasing the type makes it a local package concern, in which case, in your case, you may as well ditch the alias entirely and move the entire type into that package. In fact, your example exports the <code>controllers.Transaction</code> type, which may be unintended for consumers of your package.</p></pre>shovelpost: <pre><blockquote>
<p><code>models.Transaction</code></p>
</blockquote>
<p>Models is a not a very good package name. Same goes with <code>controllers</code>. They don't tell anything about the package. Use better package names and you won't even think about aliases anymore.</p></pre>grkuntzmd: <pre><p>@skidooer and @shovelpost: I agree with separating <code>Transactions</code> into its own package as a separate concern, and when I first started writing Go about 2 years ago, that is what I would have done, but now tend toward fewer, larger packages. In Ben Johnson's blog <a href="https://medium.com/@benbjohnson/structuring-applications-in-go-3b04be4ff091" rel="nofollow">Structuring Applications in Go</a>, in section 4, he talks about sub-packages. Because Go does not allow cyclic dependencies, it is easy to get into trouble with package <code>A</code> depending on <code>B</code> and <code>B</code> depending on <code>A</code>. I found that I had to combine <code>A</code> and <code>B</code> into some artificial package <code>AB</code> to accommodate the inter-dependency, so I stopped making so many sub-packages.</p>
<p>As far as using the type alias feature to pull a type into another package, I agree that it is not a great choice, and I was really only doing a "thought experiment". I also shy away from "." imports because they pollute the namespace unnecessarily.</p></pre>
