Interesting point. Two questions: - Is there a standard library example of a client library that provides a fake? - I've always been taught that Go packages stand alone so names like "api" and "model" are verboten. Am I wrong?
On Monday, June 19, 2023 at 1:22:03 AM UTC-4 TheDiveO wrote: > Maybe not the best way either, but the POD part might benefit from slight > refactoring and you already in part hinted at it. > > - gopher/api -- some PODs here > - gopher/model -- don't repeat gopher as in gophermodel; some PODs here > > It won't ever perfect, so YMMV. But at the same time it allows your module > to grow. > > On Monday, June 19, 2023 at 7:04:24 AM UTC+2 Salvatore Domenick Desiano > wrote: > >> I've been using Go for almost a decade and I still don't have a library >> package structure I like. I'm hoping I can post what I want here and >> someone can tell me either (a) what the idiomatic way of doing this is, or >> (a) how to break the dependency cycle. >> >> Let's imagine we're building the fancy Gopher Client library. What I want >> is: >> >> - *gopher*: public POD (plain old data) types, public interfaces, >> func NewClient(), struct clientImpl >> - *gopher/testing*: func NewFakeClient(), struct fakeClientImpl, all >> testing-specific code (*not* gopher _test files... just code for >> *other* libraries that want a fake of this one) >> - *gopher/internal*: internal types, implementation details shared >> between gopher and gopher/testing. >> >> This doesn't work. Having POD types in gopher means that everything else >> has to depend on it. This means that NewClient() can't be in gopher because >> it would depend on gopher/internal (shared implementation details) and >> gopher/internal depends on gopher (PODs). >> >> At various points I've tried: >> >> - Collapse gopher and gopher/internal. This works, but requires >> private types to be available to gopher/testing. >> - Collapse all three. This works but I really don't like having Fake >> code in the same package as real code. >> - Create gopher/gophermodel for the PODs and interfaces. This works, >> but it's really ugly to have to refer to the PODS as (for example) >> gophermodel.Response. >> - Create gopher/gopherclient for NewClient() and clientImpl. This is >> probably the least ugly but it still feel strange to call >> gopherclient.New() and have the PODs in gopher. >> >> What am I missing? >> >> Thank you! >> >> -- Salvatore >> smile. >> >> -- 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/a5003553-3c4f-429a-a5b1-9d8de43b8545n%40googlegroups.com.
