TIA,Tim.--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f4777928-875d-4c0a-a4a7-9fb57bf9d51fn%40googlegroups.com.
I don't necessarily consider the "multiple implementations" case as being truly preemptive -- if there really are multiple implementations (e.g. the "hash" package from the standard library).I'm much more concerned about interfaces that are defined by an API producer -- for one and only one impl -- and then adding a bunch of extra (often autogenerated) code to deal with that.
t.--On Monday, August 8, 2022 at 11:02:31 AM UTC-7 bse...@computer.org wrote:On Mon, Aug 8, 2022 at 11:17 AM Tim Peoples <t...@timpeoples.com> wrote:For years I've read the old adage, "Accept interfaces, return structs" and have spent years working to instill this understanding among my colleagues. I gathered a great many skills while learning Go (and acquiring readability) back in the day -- and one of the strongest of those is the idea that interfaces should be defined by their consumer instead of an API producer -- but I've now been away from Google longer than I was there and I'm beginning to suspect that the general consensus among the Go Literati may have shifted around some things -- like preemptive interfaces.My arguments against preemptive interfaces have recently run into more and more pushback -- especially among the influx of developers coming from the Java and/or C# world who seem to continually reject any notion that Go should be any different from the way they've always done things.This has recently come to a head with a brand new job (I'm 3 weeks in) where virtually all of their services are built atop a dependency injection framework having a data model with dozens (if not hundreds) of preemptive interfaces and my initial, cursory review tells me the codebase is at least an order of magnitude more complex that it needs to be. (Note, I was told that none SWEs at this company (other than myself) knew any Go before they started).So, my questions to the group are thus, "Should I even care about this at all? Are preemptive interfaces now considered the norm with Go? Or, should I just shut up and crawl back into my hole?I believe both approaches have their uses. What you call preemptive interfaces can be effectively used to hide implementation details where multiple implementations can exist. This approach can coexist very well with interfaces defined by the consumer. For example we have services that are written to implement an interface, so it becomes a logical deployment unit. Then we have consumers of that service that define parts of the interface service implements, so the consumer is not dependent on the complete service, and we can add any interceptors/filters.However, I agree with your assessment that especially newcomers tend to choose the traditional "interface is a contract" approach. In addition to the effect of other languages, people seem to like "clean architecture". Nevertheless, even with people dedicated to clean architecture, the idea of "interface parts" seems to resonate, especially when you show that you can define an interface on the consumer side that combines parts of multiple "contracts".TIA,Tim.--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f4777928-875d-4c0a-a4a7-9fb57bf9d51fn%40googlegroups.com.
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/34469b98-c37e-4a1d-af13-729b639a71ben%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3774ae88-45ea-4181-909d-f18c788c7395n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAMV2RqrP9Jy2mYhYtxo2zjjwJyMyVb8RakKwyKDaiuKwJy%3DTpw%40mail.gmail.com.
Yeah, I'm with Burak on this one. The interface usage you're describing Henry is exactly the kind of thing I'm talking about. While on the surface it may seem advantageous -- in fact, I also tried writing Go that way when I first started -- my readability reviewers at Google did well to enlighten me about the many problems this can cause with Go -- some of which rog was kind enough to enumerate.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e8bc57a6-bcee-4904-82f6-f52cdf371b6bn%40googlegroups.com.
Someone mentioned that data is data and there is no need to hide implementation details. If we are to use that reasoning, there is no need for Go to allow un-exported fields/types/functions. Why do we need them at all? The reason for hiding implementation details is to narrow down the access points to the code. By keeping the access points narrow, it reduces user's cognitive burden and leaves room for future refactoring/changes/extension to the code. It is called abstraction.
Someone also mentioned that you cannot add methods to an interface without breaking compatibility. The only case that this is true is when you have no control over the implementation. If you have control over the implementation, I don't see why you can't add methods to an interface and change its implementation in the same way you would to a struct if you are to return a struct. If you have no access to the struct, you can't add methods to the structs either. It isn't fair to consider this argument as the "return struct" superiority over "return interface".
Readability is subjective. Haskell code is often incredibly terse and elegant. Some people even swear by its readability and comprehension. While I agree that Haskell is elegant, I don't find it to be easy to read. There have been many metrics to measure code readability/comprehension/complexity over the years, and none is quite reliable. I even wrote a linter that was used in my company back then, and the tool became the company's standard that the code must pass before it can be merged to the main branch. Thinking back, what was readable back then is no longer the most readable today. Readability varies from person to person, and it changes over time.
I've come to learn that my new shop is ... utilizing ... a complete dependency injection framework and rather strict adherence to Clean Architecture™ -- (likely from the scripts in this repo) which goes a long way towards explaining why so much of the code looks like Java written in Go syntax.
For years I've read the old adage, "Accept interfaces, return structs" and have spent years working to instill this understanding among my colleagues. I gathered a great many skills while learning Go (and acquiring readability) back in the day -- and one of the strongest of those is the idea that interfaces should be defined by their consumer instead of an API producer -- but I've now been away from Google longer than I was there and I'm beginning to suspect that the general consensus among the Go Literati may have shifted around some things -- like preemptive interfaces.
My arguments against preemptive interfaces have recently run into more and more pushback -- especially among the influx of developers coming from the Java and/or C# world who seem to continually reject any notion that Go should be any different from the way they've always done things.
This has recently come to a head with a brand new job (I'm 3 weeks in) where virtually all of their services are built atop a dependency injection framework having a data model with dozens (if not hundreds) of preemptive interfaces and my initial, cursory review tells me the codebase is at least an order of magnitude more complex that it needs to be. (Note, I was told that none SWEs at this company (other than myself) knew any Go before they started).So, my questions to the group are thus, "Should I even care about this at all? Are preemptive interfaces now considered the norm with Go? Or, should I just shut up and crawl back into my hole?
TIA,Tim.--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f4777928-875d-4c0a-a4a7-9fb57bf9d51fn%40googlegroups.com.
Privacy and Confidentiality Notice: This email and all attachments are confidential and for the designated recipient(s) only. They may also be privileged. If you are not the intended recipient or among the intended recipients, you may not use, read, retransmit, disseminate, store/copy the information in any medium or take any action in reliance upon it. Please notify the sender that you have received it in error and immediately delete the entire communication, including any attachments.
On Aug 10, 2022, at 8:51 PM, 'Paolo Calao' via golang-nuts <golan...@googlegroups.com> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CABJBrS69ZRf_vaz-ChaDGjM5KStJ%3DcYuT5Tb6KnEK%3DyzONqBMA%40mail.gmail.com.