Rob Pike on Go interfaces

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'

Still a nice feat.

In the Objective-C world, you extend it with Categories and Extensions: http://developer.apple.com/library/IOs/#documentation/Cocoa/...

"I don't know why people dislike them, because the concept and the possibilities involved are quite impressive. (Combined with generics, they would be even more impressive...but that's another topic.)"

Me neither, they seem great to me (same with optional typing in Dart). For me the big advantage isn't going to be so much the compile-time checks, instead its the documentation you get in the code from it (as in you can see that an argument is a shape and quickly find out what you can do with a shape).

Have to say I've done no more than play with either language though so there could be big real-world disadvantages that I'm missing...

> I just call them static duck-typing, and then go on from there.

Duck typing is dynamically typed by definition. This is structural typing (http://en.wikipedia.org/wiki/Structural_typing) (named, sadly, OCaml allows anonymous structural types which is even neater)

Do you honestly believe that people understand "This object of this subclass has all the methods of its superclass as well as all the methods of its class" better than "This object has all the methods of its declared interface type"?

Interfaces are simple: you can do X, Y, and Z to this object. Inheritance, abstract base classes, subclasses, superclasses, etc. are all much more complicated than interfaces.

You're right, humans are good at putting things into categories. So good, in fact, that practically nothing in the real world fits into one category. I'm not just a husband; I'm also a man and a programmer and a father and an American and a Californian and so on. These are all different ways to "interface" with me. To say that a single inheritance hierarchy is more intuitive than Go's interfaces is the object-oriented version of Stockholm syndrome: your vision has been so warped by so many years of C++/Java/Python OOP that you've forgotten how unintuitive it really is.

Duck typing is simple to understand. It's the natural way to understand objects. People have been doing it (kids have been doing it!) since Smalltalk in the 80s. You don't need to have "been bitten by deep, convoluted, incestuous inheritance trees" to understand or use duck typing. You don't even need to have been so traumatized to appreciate duck typing. Interfaces are simpler than inheritance and precede inheritance mentally: even most tutorial explanations of inheritance do so using the terminology of interfaces to explain how, why, and where you'll use inheritance.

  package main
   
  type IBar interface {
  	doSomething()
  }

  type Foo int

  func (f Foo) doSomething() {
  	println(f)
  }

  func test(b IBar) {
	b.doSomething()
  }

  func main() {
	f := Foo(1)
	test(f)
  }

Compile, run:

  1

Rename doSomething function to doSomethingElse. Compile:

   test.go:20: cannot use f (type Foo) as type IBar in function argument:
	Foo does not implement IBar (missing doSomething method)

I had not heard the terms "structural subtyping" and "nominal subtyping" before, so thank you for that (Wikipedia was able to define them). And yes, I realize that Go's interfaces are implicit whereas Haskell's typeclasses are explicit.

I was thinking more along the lines that Haskell's typeclasses provide the exact same type of functionality that Rob is talking about wit Go's Interfaces, e.g. a type Foo can be a TopologicalGenus and a GrassGenus and a Square and an Area and a Symmetry all at the same time, by declaring the appropriate typeclass interfaces.

They're also somewhat similar from a usage standpoint, where in both Haskell and Go I can take a type Foo and declare methods on it that conform to a known type Bar (e.g. declaring an interface Bar Foo in Haskell, or simply declaring the methods from Bar in Go) and now my type Foo can be treated as that type Bar even if I don't control the source to Foo.

It's certainly a related problem: with Go-style implicit interfaces, neither a person nor a machine really has the context to know if something that conforms to the interface is actually intended to be used that way, or if it just happens to have the same method signatures. As you say, getName() is a pretty common sort of method name that could mean a bunch of different things, and not everything with a getName() method is necessarily interchangeable with everything else. Explicit interfaces require more work by the programmer, but make those intentions explicit to both other programmers and to automated tools.

In Gosu, we already have Java-style explicit interfaces, but we're likely going to add in Go-style implicit interfaces as a language option as well, since they're not completely interchangeable. The more I think about it, the more I think that you often want implicit interfaces for method arguments, and explicit interfaces for return values. That's oversimplifying, but as a library author you often want to say "this method works with anything that has foo() and bar() on it," so you want an implicit interface so people can use your library with existing code without changing that code to add explicit interface declarations. But if you're providing objects back as the result of a function, you might want to be more explicit and make harder guarantees about exactly what sorts of things they return.