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 explicit. When you are writing a "telegram-bot" you should know the request/response. However, when you are writing a "generic-bot" that works with "telegram" then the solution is to implement some sort of translation layer and provide a minimal API for the "generic-bot". In the end -- you will either have some shared artifact or a translation layer. I see no way of escaping it. + Egon On Monday, 13 November 2017 09:48:07 UTC+2, 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.
