Wow! Implicitly making a type conform an interface sounds like a really bad idea to me. I mean, what could possibly go wrong? Right?
I like the Swift approach way more where you can explicitly declare that an existing type conforms to an interface (called protocol in Swift) like this:
class Salad: Edible {}
No accidental conformance.
Or as the joke goes: if it walks like a duck and quacks like a duck it probably throws exceptions at runtime.
@Ruotger Deecke: Well said. The author of the article doesn't seem to realize the trouble Go programmers are gonna get in with this.
Let me make an example.
If I have an "Audio" object (parsed and instanced from a random file in a folder) and a "AnimatedGif" object (from the same folder), and both have a "Play" method, I can easily happen to pass the "Audio" object to the "AnimatedGifVisualizer" by error, because both classes have a "Play()" method.
This will work fine until the "Play()" method would be actually called, suddenly crashing everything. And you will NEVER found why. Replace this for any similar scenario using any other data types, locally or server side, and you get the same silent, untraceable crash. This implicit interface conformance thing is a debugging hell.
This is why Go will never compete with better designed langages like Swift.
Because while who designed Swift really thought about this when created Swift protocols, Go designers just throwed in features because those sounded nice at first sight, with no careful assessment of consequences.
If an error happens on your part, it isn't Go's fault for being designed badly, it's most likely yours. In order to crash the system in your example, you need to put your Audio struct in a place called AnimatedGifVisualizer...
In Go, methods have very clear meaning about what they do. If you see a method that's called CloseThenExit(io.Closer) in an io library, would you really pass in your Door struct which has a Close() method?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Wow! Implicitly making a type conform an interface sounds like a really bad idea to me. I mean, what could possibly go wrong? Right?
I like the Swift approach way more where you can explicitly declare that an existing type conforms to an interface (called protocol in Swift) like this:
class Salad: Edible {}
No accidental conformance.
Or as the joke goes: if it walks like a duck and quacks like a duck it probably throws exceptions at runtime.
@Ruotger Deecke: Well said. The author of the article doesn't seem to realize the trouble Go programmers are gonna get in with this.
Let me make an example.
If I have an "Audio" object (parsed and instanced from a random file in a folder) and a "AnimatedGif" object (from the same folder), and both have a "Play" method, I can easily happen to pass the "Audio" object to the "AnimatedGifVisualizer" by error, because both classes have a "Play()" method.
This will work fine until the "Play()" method would be actually called, suddenly crashing everything. And you will NEVER found why. Replace this for any similar scenario using any other data types, locally or server side, and you get the same silent, untraceable crash. This implicit interface conformance thing is a debugging hell.
This is why Go will never compete with better designed langages like Swift.
Because while who designed Swift really thought about this when created Swift protocols, Go designers just throwed in features because those sounded nice at first sight, with no careful assessment of consequences.
If an error happens on your part, it isn't Go's fault for being designed badly, it's most likely yours. In order to crash the system in your example, you need to put your
Audiostruct in a place calledAnimatedGifVisualizer...In Go, methods have very clear meaning about what they do. If you see a method that's called
CloseThenExit(io.Closer)in an io library, would you really pass in yourDoorstruct which has aClose()method?