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.
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'
Still a nice feat.