On Friday, June 10, 2022 at 6:48:58 PM UTC-7 ben...@gmail.com wrote:
> > I agree it might be painful, and might lead to non-idiomatic Go! But it > sounds like a really good challenge, and will no doubt teach you a lot > along the way. It looks like you've already learned something from this > thread. :-) > I certainly have. > Is the app you're converting open source, and if so, can you provide a > link to the code that leads to the import cycle? With concrete code > examples it might be easier to advise you how to refactor to avoid the > cycle. > Thanks but what I'm trying to do is so large, and probably infeasible, that I don't have any real code to show yet. The example I gave in my original posting was the result of trying various experiments. I tried to construct the example to be a minimal illustration of the problem I saw I was facing. One hack solution I came up with to break cycles when Package A depends on Package B which depends on Package A is to create a symbolic link in Package A to the file(s) in Package B that contain(s) the resources needed by Package A. Then Package A wouldn't be dependent on Package B anymore, and the cycle will be broken. (I just thought of this so I'm not 100% sure it will work until I try it). To tell the truth, the requirement that all files in a package be in the same directory will probably cause the most misery. The program I'm trying to port has so many subdirectories containing so many files that this will be a big problem. I'm thinking now that I'll have to move all the files in a package tree to the top level directory, and use a naming scheme so that I can see which subdirectory each file came from. Cordially, Jon Forrest -- 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/1b2680bd-2ac3-4c0d-89b2-21e99d272ff8n%40googlegroups.com.
