Re: [go-nuts] Rethink possibility to make circular imports
Hi everyone. I think for the moment I will agree that it would bring more pain to allow circular imports in Go than it would solve problems. One of the most convincing arguments I have read here so far is that it would probably cause many design flaws all around and make many packages very hard to maintain. I thought about suggesting allowing them in internal package but I finally don't think it's worth the efforts needed to implement that. Thank you all for your answers. Anyway if you guys have other thoughts on the subject, I'm still thinking about it so I'd like to hear them! :) Le dim. 2 déc. 2018 à 08:56, 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com> a écrit : > Anecdote: A (large) Java project I worked on ran into trouble with cyclic > dependencies so often, that they started introducing conventions like > "classes under directory X are not allowed to import classes under > directory Y (but vice-versa)", effectively emulating Go's prohibition of > cyclic imports by convention. Every once in a while, an import violating > that convention slipped through, causing issues. > > Go's prohibition of cyclic imports forces you to write your application as > a tower of abstractions, that can only traversed downwards, not upwards. > That's, in general, considered a good design principle in software > engineering - Go just makes it compiler-checked :) (on a side-note, that's > why I'm slightly uncomfortable with the notion of using interfaces to > "break import cycles" - because the functional dependency is still there, > it's just no longer visible to the compiler. But that's kinda off-topic I > guess). > > On Sun, Dec 2, 2018 at 1:31 AM David Collier-Brown > wrote: > >> I find the same, but eventually I come up with a way to clarify. Just *Not >> Real Soon* (;-)) >> >> > -- >> 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.
Re: [go-nuts] Rethink possibility to make circular imports
Anecdote: A (large) Java project I worked on ran into trouble with cyclic dependencies so often, that they started introducing conventions like "classes under directory X are not allowed to import classes under directory Y (but vice-versa)", effectively emulating Go's prohibition of cyclic imports by convention. Every once in a while, an import violating that convention slipped through, causing issues. Go's prohibition of cyclic imports forces you to write your application as a tower of abstractions, that can only traversed downwards, not upwards. That's, in general, considered a good design principle in software engineering - Go just makes it compiler-checked :) (on a side-note, that's why I'm slightly uncomfortable with the notion of using interfaces to "break import cycles" - because the functional dependency is still there, it's just no longer visible to the compiler. But that's kinda off-topic I guess). On Sun, Dec 2, 2018 at 1:31 AM David Collier-Brown wrote: > I find the same, but eventually I come up with a way to clarify. Just *Not > Real Soon* (;-)) > > -- > 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.
Re: [go-nuts] Rethink possibility to make circular imports
I find the same, but eventually I come up with a way to clarify. Just *Not Real Soon* (;-)) >>> -- 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.
Re: [go-nuts] Rethink possibility to make circular imports
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 > > wrote: > >> On Fri, Nov 30, 2018 at 6:50 AM Michel Levieux > > 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 > >> a écrit : >> >> >> >> And to reduce build time, especially for incremental builds. >> >> >> >> -rob >> >> >> >> >> >> On Fri, Nov 30, 2018 at 8:17 AM Ian Lance Taylor > > wrote: >> >>> >> >>> On Thu, Nov 29, 2018 at 5:22 AM Michel Levieux < >> m.le...@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...@googlegroups.com . >> >>> For more options, visit
Re: [go-nuts] Rethink possibility to make circular imports
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 wrote: > On Fri, Nov 30, 2018 at 6:50 AM Michel Levieux > 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 a écrit : > >> > >> And to reduce build time, especially for incremental builds. > >> > >> -rob > >> > >> > >> On Fri, Nov 30, 2018 at 8:17 AM Ian Lance Taylor > 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. > -- 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.
Re: [go-nuts] Rethink possibility to make circular imports
On Fri, Nov 30, 2018 at 6:50 AM Michel Levieux 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 a écrit : >> >> And to reduce build time, especially for incremental builds. >> >> -rob >> >> >> On Fri, Nov 30, 2018 at 8:17 AM Ian Lance Taylor wrote: >>> >>> On Thu, Nov 29, 2018 at 5:22 AM Michel Levieux >>> 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.
Re: [go-nuts] Rethink possibility to make circular imports
On Fri, Nov 30, 2018 at 8:50 AM Michel Levieux 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 a écrit : > >> And to reduce build time, especially for incremental builds. >> >> -rob >> >> >> On Fri, Nov 30, 2018 at 8:17 AM Ian Lance Taylor wrote: >> >>> On Thu, Nov 29, 2018 at 5:22 AM Michel Levieux >>> 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.
Re: [go-nuts] Rethink possibility to make circular imports
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. > Fair enough, understandable - although is it not also quite possible that the complexity you saw was (at least in part) due to circular imports? :) > 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 guess my point is the exact opposite, even if it can be structured with them it shouldn't. In my mind circularity increases package coupling whereas breaking the coupling with interfaces leads to more robust packages. No evidence either from my side (other than anecdotal) so would be interesting to hear about any studies that have been done on this. Note that Go supports this perhaps better than Java or C# due to implicit interface satisfaction. 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. > > Fair enough, I'll concede there could be situations I've not come across where not using circular imports would be more convoluted than with. Jamie -- 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.
Re: [go-nuts] Rethink possibility to make circular imports
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. 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 a écrit : > And to reduce build time, especially for incremental builds. > > -rob > > > On Fri, Nov 30, 2018 at 8:17 AM Ian Lance Taylor wrote: > >> On Thu, Nov 29, 2018 at 5:22 AM Michel Levieux >> 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.
Re: [go-nuts] Rethink possibility to make circular imports
And to reduce build time, especially for incremental builds. -rob On Fri, Nov 30, 2018 at 8:17 AM Ian Lance Taylor wrote: > On Thu, Nov 29, 2018 at 5:22 AM Michel Levieux > 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.
Re: [go-nuts] Rethink possibility to make circular imports
On Thu, Nov 29, 2018 at 5:22 AM Michel Levieux 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.
Re: [go-nuts] Rethink possibility to make circular imports
On Thu, Nov 29, 2018 at 2:22 PM Michel Levieux wrote: > The main reason why I'm strongly convinced forbidding circular imports is not a good thing is that it separates too much the problem space from the solution space. TBH, I cannot even figure out how could _possibly_ circular imports work. Have you considered also https://golang.org/ref/spec#Program_initialization_and_execution in your thoughts? Anyway, can you provide a small example of two packages, importing each other, illustrating the advantage of circular imports? I'm not sure, but I feel it can be proven that it's always possible to reorganize those two packages to do not depend on circular imports. And transitively for N packages. But I'm really just guessing. -- -j -- 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.
Re: [go-nuts] Rethink possibility to make circular imports
Can I suggest you provide a real example to help motivate why you think circular package imports should work, and therefore what they would solve? I will note that circular module dependencies are possible and have good reasons to exist (https://github.com/go-modules-by-example/index/blob/master/013_cyclic/README.md) On Thu, 29 Nov 2018 at 13:22, Michel Levieux 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. > > I'm a young developer (not particularly in Go, I have only 2-3 years of > experience at total) so I'm looking forward to hearing your opinion guys, but > I think Go2 should allow importing packages circularly. I have no practical > reason to think that, except I've been tricking many times to have a > structure in my project with which I can at least build. > > The main reason why I'm strongly convinced forbidding circular imports is not > a good thing is that it separates too much the problem space from the > solution space. In Golang, the majority of the solutions we find are just the > translation of the logic behind our head into a language a computer can > understand - I emphasize this because it might not be true for all languages > (take Prolog for instance). Most of the time when you read a well written > program, you clearly get the underlying logic that led to this particular > solution, AND implementation of the solution. > > BUT - I think that there are some cases (and not just a few) when from a > logical point of view, the solution is clear, and we have to take the > structure of a project away from that logic, because circular imports are not > permitted. The human brain works in such a manner that circular imports make > sense, and I'll get even further, they are what makes the strongest sense of > all the solutions it can get to. > > That is my one and only point, but I personally think it is enough to at > least discuss the issue. > > I have many questions from this point : > - Has there been any discussions about that for Go2 yet? If yes, could any of > you point me to them? > - What do you think about what I just wrote? Is it coherent and relevant or > am I missing something? > - Do you see any alternative to the problem I brought here other than > authorizing circular imports? > - Can anyone explain me exactly why circular imports are forbidden or is this > too complicated to hold in a mail? > > Thank you all for reading! > > -- > 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.
[go-nuts] Rethink possibility to make circular imports
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. I'm a young developer (not particularly in Go, I have only 2-3 years of experience at total) so I'm looking forward to hearing your opinion guys, but I think Go2 should allow importing packages circularly. I have no practical reason to think that, except I've been tricking many times to have a structure in my project with which I can at least build. The main reason why I'm strongly convinced forbidding circular imports is not a good thing is that it separates too much the problem space from the solution space. In Golang, the majority of the solutions we find are just the translation of the logic behind our head into a language a computer can understand - I emphasize this because it might not be true for all languages (take Prolog for instance). Most of the time when you read a well written program, you clearly get the underlying logic that led to this particular solution, AND implementation of the solution. BUT - I think that there are some cases (and not just a few) when from a logical point of view, the solution is clear, and we have to take the structure of a project away from that logic, because circular imports are not permitted. The human brain works in such a manner that circular imports make sense, and I'll get even further, they are what makes the strongest sense of all the solutions it can get to. That is my one and only point, but I personally think it is enough to at least discuss the issue. I have many questions from this point : - Has there been any discussions about that for Go2 yet? If yes, could any of you point me to them? - What do you think about what I just wrote? Is it coherent and relevant or am I missing something? - Do you see any alternative to the problem I brought here other than authorizing circular imports? - Can anyone explain me exactly why circular imports are forbidden or is this too complicated to hold in a mail? Thank you all for reading! -- 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.
