Re: [go-nuts] Re: Code-base Refactoring Tool for Go , Move files from packages to sub packages

On 15 December 2016 at 19:52, Dave Cheney wrote: > How do aliases help this situation? In my view they'll just obscure the > true source of the declaration. > People in a hurry will continue to create bad dependencies whether or not we have aliases, but perhaps aliases might

Re: [go-nuts] Re: Code-base Refactoring Tool for Go , Move files from packages to sub packages

How do aliases help this situation? In my view they'll just obscure the true source of the declaration. On Fri, 16 Dec 2016, 02:46 Alan Donovan wrote: > On 15 December 2016 at 04:38, roger peppe wrote: > > In my experience it is very common for circular

Re: [go-nuts] Re: Code-base Refactoring Tool for Go , Move files from packages to sub packages

On 15 December 2016 at 04:38, roger peppe wrote: > > In my experience it is very common for circular dependencies to arise > not because > of something in a package that I'm using directly, but because of > something semi-related that > happens to sit in the same package. >

Re: [go-nuts] Re: Code-base Refactoring Tool for Go , Move files from packages to sub packages

On 14 December 2016 at 21:11, Dave Cheney wrote: > I've retired hurt from the alias debate, but I'll bet you a steak dinner > next time I'm in NYC that aliases will have caused an unexpected increase in > circular dependency problems because aliases obscure the true declaration

[go-nuts] Re: Code-base Refactoring Tool for Go , Move files from packages to sub packages

On Thu, 15 Dec 2016, 07:50 Alan Donovan wrote: > On 14 December 2016 at 15:13, Dave Cheney wrote: > > For example, net/http contains both http client and server facilities, > because they both relate to the use of http. The prevailing style in other >

[go-nuts] Re: Code-base Refactoring Tool for Go , Move files from packages to sub packages

On 14 December 2016 at 15:13, Dave Cheney wrote: > For example, net/http contains both http client and server facilities, > because they both relate to the use of http. The prevailing style in other > languages would have these placed in separate packages, one for client, one >

[go-nuts] Re: Code-base Refactoring Tool for Go , Move files from packages to sub packages

As an aside, I find that many programmers have a strong desire to aptly taxonomies to their work, they want to find _differences_ between two things so they can be separated and classified. I think to write successful Go, you should look for similarities and combine things with a similar

[go-nuts] Re: Code-base Refactoring Tool for Go , Move files from packages to sub packages

It's pretty consistent with the message I've been pushing for a while; each package should have a well defined purpose, and that purpose should be enumerated by the pacakge's name. I find that when I apply that logic to my own projects, I tend to have less packages, not more. On Thursday, 15

[go-nuts] Re: Code-base Refactoring Tool for Go , Move files from packages to sub packages

On Tuesday, 13 December 2016 20:06:49 UTC-5, Dave Cheney wrote: > > I advice caution, Go is not Java and does not permit circular > dependencies. The more packages you have, the greater the chance you have > of creating a circular dependency. > That's a rather dark viewpoint. Absent further

[go-nuts] Re: Code-base Refactoring Tool for Go , Move files from packages to sub packages

I advice caution, Go is not Java and does not permit circular dependencies. The more packages you have, the greater the chance you have of creating a circular dependency. On Wednesday, 14 December 2016 00:58:00 UTC+11, jis...@hifx.co.in wrote: > > > >

[go-nuts] Re: Code-base Refactoring Tool for Go , Move files from packages to sub packages

On Tuesday, 13 December 2016 08:58:00 UTC-5, jis...@hifx.co.in wrote: > > > > http://stackoverflow.com/questions/41121448/code-base-refactoring-tool-for-go-move-files-from-packages-to-sub-packages > > Currently my code-base have just 1 level of packages , due to the increase > in number of