I forgot to mention that the main way to work around this limitation has to do with separating declarations of types shared by the two otherwise circularly importing packages. But it gets tricky again then when it comes to defining methods on the types, because you can't declare methods on nonlocal types. I think for that you need type aliases.
Like many aspects of Go, you have to think like the computer to express your intent correctly. On Thursday, 6 December 2018 04:05:36 UTC+1, Louki Sumirniy wrote: > > The main reason for the prohibition against circular imports is that you > have to add overhead in the processing to determine when to stop. From an > architectural perspective it also makes sense - most often if you stop for > a moment and think about what you are building, usually if you are needing > a circular import, the two packages really are part of one package. > > In C/C++ preprocessor, the #pragma once is often liberally spiced all over > the package to stop the compiler overrunning the cycles. This makes for a > nightmare for attempting to splice out part of it, and obviously is costing > a lot of time for every compilation, especially when only part has changed, > circular imports require re-parsing the whole thing all over again. > > I think this is the one situation where it makes sense to use dot imports. > > But the more you learn about go, the more you realise that the main > benefits of go come from forcing the programmer to have a reasonable grasp > of the underlying mechanisms at play. You can't get such fast compilation > when you force the compiler to think like a human, and it is easier to > instead get the human to think like the compiler. As a long time low-level > programmer, my first languages being BASIC and Assembler, I didn't need to > have this explained to me when I saw go. When I really learned what Go is > all about, it immediately reminded me of a funny little language from the > early 90s called Amiga E. It also used an extremely simple top level > structuring, which yes also is where Go shares much with Pascal and its > family of languages. Pascal was considered to be a good teaching language > for this reason, and Wirth designed these languages with the complexity of > the compiler in mind, again, humans can think (slowly) like computers, but > computers think even slower, the more human-like you try to make the > processing. > > If performance is not an issue, and complexity of managing the codebase is > not an issue, you probably also might consider that you don't want to use > Go at all. Go has an energetic name because performance is central to its > design goals, and in computer programming, performance flows naturally from > conforming to the limitations of the hardware. Heuristics can often make > good decisions but when it fails, you can be lost for trying to eliminate > the problem, and this is not acceptable for high speed, mission critical > database systems especially. > > On Thursday, 29 November 2018 14:23:04 UTC+1, 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.
