I probably have a parsing problem here. Can you help me solve it?
Knowing not a lot about Go I followed the links and saw that interfaces are 'implemented' implicitly, the quacks like a duck way. If I fulfill the contract of an interface I can be used as something of that interface. Cool.
But - what is Rob's comment now?
"It's always bothered me in OO languages that we can make Circle, Square, etc. subclasses of Shape (say), but that's the one design decision we get to make. What if we want to align those things along other axes (so to speak), like topological genus or plant genus, if you're a landscaper? You might lose your way or dig yourself into a hole with multiple inheritance." (goes on, imo down the same route)
From what I can tell there's no issue here. Except for the requirement to be explicit (implements Foo, Baz, Baz) instead of implicit (just add those interfaces' methods on your type) the very same thing can archived in the biggest (market share?) OO languages. Java? Check. C#? Check.
What exactly is leading to this final quote:
"Go's interfaces aren't a variant on Java or C# interfaces, they're much more. They are a key to large-scale programming and adaptable, evolutionary design."
I'm honest here. I don't get it. Duck typing? Yeah, fine. I think I'd like that. But what am I missing? It seems in Go you get two things: No need to explicitly annotate the types with the classes it implements (good or bad, probably depends on taste and general complexity of the code) and, perhaps bigger?, you can probably extract interfaces later which are now magically implemented. But both features seem to be ~refactoring/design~ details. Nifty maybe, if they fit your style. But not a leap in any way?
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.
One of the main advantages is that you can write interfaces which works on code in libraries you don't control, so something written without the interface in mind can 'implement' an interface added later.
Knowing not a lot about Go I followed the links and saw that interfaces are 'implemented' implicitly, the quacks like a duck way. If I fulfill the contract of an interface I can be used as something of that interface. Cool.
But - what is Rob's comment now?
"It's always bothered me in OO languages that we can make Circle, Square, etc. subclasses of Shape (say), but that's the one design decision we get to make. What if we want to align those things along other axes (so to speak), like topological genus or plant genus, if you're a landscaper? You might lose your way or dig yourself into a hole with multiple inheritance." (goes on, imo down the same route)
From what I can tell there's no issue here. Except for the requirement to be explicit (implements Foo, Baz, Baz) instead of implicit (just add those interfaces' methods on your type) the very same thing can archived in the biggest (market share?) OO languages. Java? Check. C#? Check.
What exactly is leading to this final quote:
"Go's interfaces aren't a variant on Java or C# interfaces, they're much more. They are a key to large-scale programming and adaptable, evolutionary design."
I'm honest here. I don't get it. Duck typing? Yeah, fine. I think I'd like that. But what am I missing? It seems in Go you get two things: No need to explicitly annotate the types with the classes it implements (good or bad, probably depends on taste and general complexity of the code) and, perhaps bigger?, you can probably extract interfaces later which are now magically implemented. But both features seem to be ~refactoring/design~ details. Nifty maybe, if they fit your style. But not a leap in any way?