[jerf]

How do you fail to implement the second method override on a single-method interface?

Bear in mind that when using the interface, the interface is all there is. It essentially erases the other methods from consideration. That's why an interface value in Go is a distinct type; it isn't just "a thing that can happen to hold all these various concrete values", it is a distinct thing with its own method set. So discussion underlying structs and their method sets is a category error. (This is a bit subtle, but important to understand what is actually going on in Go, or any other language with a similar setup.)

I'm not talking hypothetically. I'm talking about what happens in real Go code. Discussing what could happen if people wrote interfaces in a way other than they actually do is what is hypothetical. This is the sort of thing that matters when deciding whether or not a particular pattern is useful in a language. It's rarely entirely down to pure syntax concerns or some sort of Platonic software engineering consideration. In fact, even within the same language you can encounter situations where a pattern makes sense in one framework but is a bad idea in another framework; Javascript is full of such things. (Whether that's for good or bad reasons is a separate consideration; the fact is that it is full of them.)

[jayd16]

>How do you fail to implement the second method override on a single-method interface?

Well in the example given, there is an interface Client with two methods. If a maintainer controls the Client interface and the HTTPClient implementation, the case can occur where that maintainer updates Client and HttpeClient. Suddenly, CachedHTTPClient in the downstream project has an unchached method and as far as my limited Go knowledge goes, no compiler error.

>I'm talking about what happens in real Go code

The case appears in the blog post. Would you say the blog is not idiomatic Go?

[jerf]

"Would you say the blog is not idiomatic Go?"

Yes, it's a contrived example to make the point in the blog. Blog samples have to be taken that way. The vast majority of the time real code decorates in Go, it's with either A: an interface of 1 method or B: something sufficiently local in concern that this sort of thing isn't a concern, beyond it just being a bug (a compiler forcing you to specify an override won't save you from just sticking the minimal stub in). Part of why this can be a problem in Java is you tend to get a certain sprawl to your class hierarchy that doesn't occur in Go. Or most other languages, used well. Java's got some unique weaknesses in this area that do not generally translate.

[jayd16]

I personally think it has more to do with the coders than the code. Seeing as it's trivial to do it wrong in Go (see blog) I have to assume IBM websphere Go would be a similar nightmarish hellscape as it is in Java.