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 <https://github.com/go-telegram-bot-api/telegram-bot-api>). Requests and responses from the API are big, fat JSONs; wrapped up in Go structs. These Go structs are the one in question. As it can be seen, they are pretty big and bulky (can not be helped, it's how the Telegram API is). But passing them up/out, makes other packages, become dependent on *tgbotapi* package. As for functionality, interfaces work great. But for payloads that are being passed between packages (even if they are POGOs) I can not find a clean approach for sharing them. On Monday, November 13, 2017 at 11:05:07 AM UTC+3:30, Egon wrote: > > 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, return concrete types". >> Which helps greatly in implementing different architectures/designs (like >> Clean Architecture or the like). >> >> There are times that a package is used which returns fat structs (as the >> concrete type) - mostly POGO. >> >> Problem: >> Redefining some domain models for those payloads is cumbersome and >> sometimes impractical. At the same time using them directly, exposes other >> packages to that package that we want to abstract out it's functionality. >> Some unwelcome dependency. >> >> Question: >> Should we redefined all those data types in upper layers for using them? >> If no what is the solution? >> > -- 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.
