Re: [go-nuts] Preemptive interfaces in Go

I would say to temper judgement on both sides. If you’ve ever written or read Go code in an IDE and used “find implementors” you’ve seen the power of interface based design. Sure, you can still do this in Go - kind of - because an implementation may not be by design nor according to the semant

Re: [go-nuts] Preemptive interfaces in Go

On Mon, Aug 8, 2022 at 7:17 PM Tim Peoples 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

Re: [go-nuts] Preemptive interfaces in Go

On Wed, 2022-08-10 at 11:17 -0700, Mike Schinkel wrote: > In my experience having control over the implementation is not a > black-and-white thing, unless you are the sole developer on a > project. This also brings in the consideration of that if you have complete control over the implementation,

Re: [go-nuts] Preemptive interfaces in Go

On Tuesday, August 9, 2022 at 3:52:13 PM UTC-4 t...@timpeoples.com wrote: > I've come to learn that my new shop is ... utilizing ... a complete > dependency injection framework and rather strict adherence to *Clean > Architecture*™ >

Re: [go-nuts] Preemptive interfaces in Go

Responses inline... On Wednesday, August 10, 2022 at 1:17:21 AM UTC-7 Henry wrote: > 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

Re: [go-nuts] Preemptive interfaces in Go

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 po

Re: [go-nuts] Preemptive interfaces in Go

I'm Sorry -- when I said "readability reviewer" I was referring to a very google-specific term about how they ensure the author of a change understands the language they're writing. Granted, it's been a while since I worked there but, at that time, each change request (aka MR, PR, etc...) requi

Re: [go-nuts] Preemptive interfaces in Go

On Tue, Aug 9, 2022 at 1:52 PM Tim Peoples wrote: > 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

Re: [go-nuts] Preemptive interfaces in Go

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 enli

Re: [go-nuts] Preemptive interfaces in Go

One significant argument against preemptive interfaces is that you can't add a method to an interface type without breaking compatibility. Also, an interface is significantly less amenable to static analysis because it's not certain where a method call is implemented. One concern I have about the

Re: [go-nuts] Preemptive interfaces in Go

On Mon, Aug 8, 2022 at 11:27 PM Henry wrote: > I am sure that many of us have been on that journey. After using Go for > some time, we discover some practices that are not necessarily in agreement > with the existing "adages" but effectively solve our problems. > > For me, if the data type is mut

Re: [go-nuts] Preemptive interfaces in Go

I am sure that many of us have been on that journey. After using Go for some time, we discover some practices that are not necessarily in agreement with the existing "adages" but effectively solve our problems. For me, if the data type is mutable, I prefer returning interfaces. It would be so

Re: [go-nuts] Preemptive interfaces in Go

I can't speak to the *auto-generated swagger client* case but I believe gRPC is still doing things the right way -- in that the framework defines an interface I (the framework API consumer) then implements. IOW: I don't see that as a "java style interface" (where the interface defines the API

Re: [go-nuts] Preemptive interfaces in Go

On Mon, Aug 8, 2022 at 12:51 PM Tim Peoples wrote: > 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 tha

Re: [go-nuts] Preemptive interfaces in Go

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 im

Re: [go-nuts] Preemptive interfaces in Go

On Mon, Aug 8, 2022 at 11:17 AM Tim Peoples 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

[go-nuts] Preemptive interfaces in Go

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