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 layer, the package B is placed, which provides a nice set of abstractions for package A. In a use-case package named C, those abstractions from package B is used.
So far, so good! Now, as explained, package A has those bulky fat payloads; which forces us to use package A, directly inside package C. This nullifies the purpose of package B. This indeed, happens when a generic bot is being implemented. But even if that was not the case, I failed to find a way to prevent A from leaking into C. At the end of the day it's all about trade-offs! I think you are right that there is no other way around and we have to either use A directly or write a translation layer. Yet I'm curious about using type aliases as (yet another level of) an indirection. On Monday, November 13, 2017 at 12:00:27 PM UTC+3:30, Egon wrote: > > 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.
