On Thu, Jun 9, 2022 at 7:06 PM jlfo...@berkeley.edu <jlforr...@berkeley.edu> wrote:
> How can this program be made to work? I've tried many things, which all >>> lead back >>> to the situation I describe above. >>> >> >> You need to refactor the code to eliminate the import cycle. >> https://jogendra.dev/import-cycles-in-golang-and-how-to-deal-with-them >> > > As a learning exercise I'm converting a large app into Go. > That's going to be a painful way to learn Go. Worse, doing a straightforward, mechanical, translation of a program written in another language is likely to result in non-idiomatic Go code and reinforce bad habits (bad in the context of Go, not the other language). > The app's source code > is located in many directories, and I've already learned that all files in > a package have to be located > in the same directory so that rules out the suggestion in the posting > above to put everything in > one package. (What's the reason for this requirement)? > Technically, that is an implementation detail of a particular Go toolchain. >From https://go.dev/ref/spec#Packages: > An implementation may require that all source files for a package inhabit the same directory. I don't know why the official (primary?) Go toolchain imposes that restriction. If you google "golang package structure multiple directories" you can find discussions of this question. Such as https://stackoverflow.com/questions/45899203/can-i-develop-a-go-package-in-multiple-source-directories . I'm guessing the app you're translating is written in Java and you're comfortable with that language. I've only written a trivial amount of Java code but did start writing Go a few years ago after using Python as my primary language for several years (and, C, COBOL, FORTRAN, and many other languages before that). All I can say is that you really need to avoid imposing idioms from language J on language G. At least if you want to be successful at writing high quality code in language G. So, I'll probably have to keep using multiple packages if I can somehow > figure out how to solve > the package import cycle problem. > The most common solution is to factor out the aspects which cause the cycle into a third package that one or both of the current packages imports. In my four decades of programming I've only seen one import cycle (in Python) that was hard to remove. My team eventually used the "Python lazy import" hack. Refactoring the code to eliminate the import cycle, and therefore the hack to handle it, was high on my team's priority list when I left the project. -- Kurtis Rader Caretaker of the exceptional canines Junior and Hank -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD9ugevVN3g8%3D%3DfQaCm8vAj4oTfF4tYR6zQf9Yt%3D9UTnJw%40mail.gmail.com.
