Ok, so you're missing the main point. Suppose you have a library that isn't yours, and you don't have the source code. But, it has a type "Foop" that doesn't implement any of the interfaces you'd like it to for your purposes. What do you do? In the Java world, you make a subclass and implement those interfaces. We probably call that the Adapter pattern or something.
In the Go world, or the Haskell world, or even the Clojure world, we say, "No problem. I'll just extend Foop with this interface by adding these 3 methods."
Extending/adding those methods doesn't change Foop though. Foops are still Foops and can still be used as is with the library that Foop was bundled with. They just now implement a new interface for my purposes.
Just to be sure: You suggest to write interfaces ('extract' in my original post as that seems to be the refactoring name you'd use for this kind of stuff in my world) that define a contract for pre-existing characteristics of 3rd party types?
Or are you, as I read your sentence in quotes, talking about some kind of monkey patching of the original classes?
I understand your point, but I don't understand the original post/mail. Interfaces per se still seem to be the exact same thing, simple contracts, and types can fulfill multiple of those. I guess my main problem is that for me this is not a discussion about interfaces, this is a discussion about orthogonal language features which might happen to allow you to use interfaces a little more liberal.
That's why I started with my assumption of a parsing error: Reading the mail I'd summarize that as 'Go interfaces are awesome and much better than C#/Java equivalents' while the little amount of understanding I have right now lends itself far better to 'Go interfaces are - well - just like any other interfaces out there. But! We can weave them magically (java: AOP?) and implicitly in at runtime'
"Just to be sure: You suggest to write interfaces ('extract' in my original post as that seems to be the refactoring name you'd use for this kind of stuff in my world) that define a contract for pre-existing characteristics of 3rd party types?"
No, in Go you can write new methods for pre-existing 3rd party types that you do not have the source for. It has the feel of monkey patching, but there is no classes in Go. A method is just a function that takes objects of certain type as a parameter. Knowing an object's type does not tell you what actions can be performed on it. To know that, you want to know what interfaces the object implements.
This is a one way to solve the so called expression problem, which cannot be solved by simple use of classes and interfaces in a language like Java.
In the Go world, or the Haskell world, or even the Clojure world, we say, "No problem. I'll just extend Foop with this interface by adding these 3 methods."
Extending/adding those methods doesn't change Foop though. Foops are still Foops and can still be used as is with the library that Foop was bundled with. They just now implement a new interface for my purposes.