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 still do not feel being confident that the approach is proper or not. On Monday, November 13, 2017 at 11:18:07 AM UTC+3:30, dc0d wrote: > > 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.
