I've found that I end up lumping a bunch of things together into a much larger package than I'd prefer precisely because there is often no good way to break a logical piece out into its own package without creating a circular dependency. For me at least, this makes the code harder to navigate because I then have to search through a large set of files in a single directory.
Admittedly, some of this is due to my desire to reduce name clutter. For example, rather than naming a bunch of related "Bar" functions something like "foo.BarXXX" in a "foo" package, I'd rather move them into a "bar" package and just use "bar.XXX". Note that whether the code is all in one package or broken into separate packages that required each other makes zero difference with regards to how much code is pulled in. I do agree that not having the ability to create cycles is generally good... but there are times when it ends up being very painful. On Friday, November 30, 2018 at 8:40:31 AM UTC-8, rog wrote: > > In my view, Go's prohibition on cyclic imports is perhaps *the* single > most important feature that keeps large Go projects sane. > > There are numerous occasions in the last few years when we would have used > cyclic imports if they were available, and in every case it would have been > a mistake. In some cases, we needed to do some significant refactoring work > to avoid a cycle - that's why we'd have gone the easy route if it were > available > > The problem is that if you allow cyclic imports, any large project has a > tendency to turn into a giant ball of mud, where importing any part of the > ball brings the whole thing along withit. > > The cyclic import prohibition also means portions of a large project have > more tendency to be reusable, as they don't depend on all the rest of the > project. It also means that refactoring is significantly easier because > refactoring can proceed bottom-up. > > > On Fri, 30 Nov 2018 at 14:44, Burak Serdar <bse...@ieee.org <javascript:>> > wrote: > >> On Fri, Nov 30, 2018 at 6:50 AM Michel Levieux <m.le...@capitaldata.fr >> <javascript:>> wrote: >> > >> > Hi guys, >> > >> > I've been trying to find examples of cases where it is complicated to >> structure the project because circular imports are forbidden, but I can't >> find something simple that I can show you. The thing is when I've been >> confronted to such cases, it was with large projects, and I have no simple >> way of reducing it to anything that can stand in a mail. >> >> Is this in the context of a porting effort from another language? I >> found myself using circular package dependencies numerous times when I >> wrote Java code, especially in situations where a complicated parent >> package is broken into multiple sub-packages that depend on the >> parent. I wouldn't structure the code that way if I wrote it in go, so >> maybe some redesign and some refactoring may eliminate the need for >> circular dependencies. >> >> > >> >> Maybe it would help if you gave an example of some code that you think >> requires circular imports and we can see if it can be restructured without? >> > >> > >> > I know that most projects can be restructured without circular imports, >> but my point is that sometimes, even if it can be restructured without >> them, it should not. I don't really know how to convey clearly what's in my >> mind, maybe I'm wrong in my conclusions, but I've thought a lot about this >> and it makes me uncomfortable. From my own perspective, if the logical >> resolution of a problem leads to a structure with loops in its semantics >> and construction, the language should not require rethinking such solution >> so that there are no more loops in its architecture. >> > >> > I'm gonna keep trying to find a really simple and clear use case, and >> I'll get back to you guys when I find one. >> > >> > Le jeu. 29 nov. 2018 à 23:30, Rob Pike <r...@golang.org <javascript:>> >> a écrit : >> >> >> >> And to reduce build time, especially for incremental builds. >> >> >> >> -rob >> >> >> >> >> >> On Fri, Nov 30, 2018 at 8:17 AM Ian Lance Taylor <ia...@golang.org >> <javascript:>> wrote: >> >>> >> >>> On Thu, Nov 29, 2018 at 5:22 AM Michel Levieux < >> m.le...@capitaldata.fr <javascript:>> wrote: >> >>> > >> >>> > The last few days I've been thinking a lot about the fact that Go >> does not allow circular imports. >> >>> > I'm not really sure of why it currently works that way, but from >> what I've understood the way the compiler works - which is also the reason >> why compilation of Go programs is much faster than other languages - makes >> it quite difficult to authorize circular imports. >> >>> >> >>> That's not the real reason. The real reason is to make program >> >>> initialization as clear and unambiguous as possible. >> >>> >> >>> Ian >> >>> >> >>> -- >> >>> You received this message because you are subscribed to the Google >> Groups "golang-nuts" group. >> >>> To unsubscribe from this group and stop receiving emails from it, >> send an email to golang-nuts...@googlegroups.com <javascript:>. >> >>> For more options, visit https://groups.google.com/d/optout. >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups "golang-nuts" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an email to golang-nuts...@googlegroups.com <javascript:>. >> > For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
