On Fri, Nov 30, 2018 at 6:50 AM Michel Levieux <m.levi...@capitaldata.fr> 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> a écrit : >> >> And to reduce build time, especially for incremental builds. >> >> -rob >> >> >> On Fri, Nov 30, 2018 at 8:17 AM Ian Lance Taylor <i...@golang.org> wrote: >>> >>> On Thu, Nov 29, 2018 at 5:22 AM Michel Levieux <m.levi...@capitaldata.fr> >>> 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+unsubscr...@googlegroups.com. >>> 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. -- 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.
