Look, I understand duck typing. Go doesn’t have it, the fact you keep calling go’s dynamic dispatch duck typing is a bit of a red flag, but I can see why you would think that. It’s not my point though, you’re missing what I’m saying.
You’re saying, essentially, that you just use the objects method and you don’t need to read its implementation to understand what it does, if something has a “Update” method and it takes a new copy of the object and it’s a pointer method, as a caller we can assume that we give the new data to that update method and it’ll just take that data and patch it into the object at that pointer address. You don’t have to read the method and go on with your day, the interface proves it works and you don’t need “implements”
The problem with this is there are bad programmers who do crazy things with “Update”. Some people will kick off go routines that do things later and mutate things you don’t expect. So when you fetch 500 things then update them in a loop and suddenly nuke your database with 50,000 writes simultaneously that are all contending for the same key, you will go back to Update and see… oh fuck this update method uses some clever Postgres queue and keeps a lot of metrics that are also in Postgres, that’s why my system locked when it shouldn’t have. I should have read this Update method.
So that is crux of my point. Having the method name and function parameters only is not enough to understand your program, and using single interface definitions all over the place hurts readability and understanding.
> You’re saying, essentially, that you just use the objects method and you don’t need to read its implementation to understand what it does
Your recent points have nothing to do with mine. What you're thinking that I'm saying is not what I'm saying. I'm still very much aligned with the original topic of the article, Interface Segregation as it's done in Go. An article to which you reacted adversely, while demonstrating that you're clearly still looking for Java where it doesn't exist. I'll leave things at that, since I'd just be repeating myself at this point.
I’m not a Java dev, my preferred languages are Clojure, scala, rust, and python. I think you assumed ignorance, tried to explain something your colleagues probably don’t get to someone who understands it, and then haven’t put the effort into reading the link I sent earlier, and I’ve failed miserably at explaining my point.
I think you’d have to have seen the problem, and maybe it only pops up in a large go monorepo that uses DI the IDE can’t see through, while simultaneously having to work with interfaces like “Get” where some of the implementation was written by devs who think Get is a mutation.
You’re right though. We’re talking past each other and both think the other one is a moron. Leave it to the reader to figure out which one is I suppose.
You’re saying, essentially, that you just use the objects method and you don’t need to read its implementation to understand what it does, if something has a “Update” method and it takes a new copy of the object and it’s a pointer method, as a caller we can assume that we give the new data to that update method and it’ll just take that data and patch it into the object at that pointer address. You don’t have to read the method and go on with your day, the interface proves it works and you don’t need “implements”
The problem with this is there are bad programmers who do crazy things with “Update”. Some people will kick off go routines that do things later and mutate things you don’t expect. So when you fetch 500 things then update them in a loop and suddenly nuke your database with 50,000 writes simultaneously that are all contending for the same key, you will go back to Update and see… oh fuck this update method uses some clever Postgres queue and keeps a lot of metrics that are also in Postgres, that’s why my system locked when it shouldn’t have. I should have read this Update method.
So that is crux of my point. Having the method name and function parameters only is not enough to understand your program, and using single interface definitions all over the place hurts readability and understanding.