[go-nuts] Re: Bulky (Payload) Structs in API

Thanks! The bot package was just an example. This is a general concern IMHO. Interfaces do nicely when we want to hide implementation details (on accepting things as an interface). For example package A is a low-level, infrastructure package at Infrastructure layer/area. Now at the Interfaces

[go-nuts] Re: Bulky (Payload) Structs in API

Is there a problem created from sharing the package or creating a separate package? Or why is that dependency a problem? There's some knowledge about the requests/responses shared between packages. Trying to hide it, doesn't gain anything -- it only makes the sharing implicit rather than explic

[go-nuts] Re: Bulky (Payload) Structs in API

BTW another approach that I've tried is to use Type Aliases. A third package created and type aliases (with the same names) defined for those POGO payloads. Then type aliases (and interfaces) from this third package can be used in upper/other packages. But I've not used it heavily because I st

[go-nuts] Re: Bulky (Payload) Structs in API

Thanks! That's what I do, though not happy with it. I had to write some helper apps and scripts (I'm not fluent in playing with Go ast yet). An example would be the API to Telegram Bot (package ). Requests and responses from the API are

[go-nuts] Re: Bulky (Payload) Structs in API

One possibility is copy-paste the structure and convert at call boundaries. https://play.golang.org/p/5LFw6U3yi6 But, can you show a real-world example to ground the conversation? + Egon On Monday, 13 November 2017 08:48:18 UTC+2, dc0d wrote: > > It is a Go best practice to "accept interfaces,