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 <dav...@spamcop.net> 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.
