On Fri, Nov 30, 2018 at 8: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. > How about find a *single* dependency cycle in a large project (if there are many, find the shortest), and then briefly describe it and justify the cycle? If you don't want to reveal internal details of a closed source project, you can just rename the components, as long as their new name is at least abstractly indicative of the component's purpose. You may even get good replies about good ways to re-organize the example to break the cycle -- perhaps in a clean way that you haven't yet considered. > > 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.
