how safely could i use the "import dot" feature?

<p>i&#39;m building a framework, and i want to use the import dot feature lightly,<br/> it just will make the API looks great<br/> so what limitations i could restrict myself to it, to not facing any errors doing this?</p> <hr/>**评论：**<br/><br/>quiI: <pre><p>I would recommend against it. Just obfuscates where a function/struct/whatever comes from when reading code. </p></pre>kpmy: <pre><p>Just like &#34;make&#34; or &#34;append&#34;.</p></pre>nemith: <pre><p>If you are using import . a lot then maybe you are trying to hard to make packages more like fancy name spaces. </p> <p>I find a lot of go programs i find on Github use WAY too many packages. One is probably enough. </p></pre>junajted: <pre><p>One limitation (main?) is there can&#39;t be two exported identifiers (structs, functions,...) with the same name (i.e. <code>pkg1.Man</code> and <code>pkg2.Man</code>, assuming both packages will be imported with dot), but that doesn&#39;t apply for unexported identifiers.</p></pre>mrwnmonm: <pre><p>yeah, i know this is the main idea<br/> but because the go team doesn&#39;t recommend using it, i thought there are other things could cause errors</p></pre>barsonme: <pre><p>That&#39;s pretty much the worst reason. Why do it?</p> <p>Is writing</p> <pre><code>bytes.Compare </code></pre> <p>That much more work than</p> <pre><code>Compare? </code></pre> <p>Edit: I meant to type &#34;only&#34; instead of &#34;worst&#34; but autocorrect hates me. </p></pre>junajted: <pre><p>Maybe this library will be a big and OP will want to refactor it to multiple files (possibly creating sub-packages too) and at the end of the day he&#39;s going to offer library&#39;s API under a single namespace.</p></pre>[deleted]: <pre><p>I think if you are writing code that other people (including yourself a few months later) will read then you shouldn&#39;t use dot imports. Instead give your package an easy to read name that combines well with function names inside the package.</p></pre>robbles: <pre><p>I believe some of the common code tooling, like &#34;godef&#34;, will have trouble with this practice as well.</p> <p>Recently I used a package whose github repo didn&#39;t match it&#39;s package name, and the resulting implicit name broke several of these tools. I&#39;m guessing godef and oracle would not be able to find the definitions with an &#34; import dot&#34;</p></pre>THUNDERGROOVE: <pre><p>I only do it when I&#39;m importing my own packages</p></pre>