Comment by akeefer | Hacker News Reader

Comment by akeefer | Hacker News Reader

In general I like the way Go interfaces work (we'd like to do something similar in Gosu as well); they let you decouple different parts of a system much better than you can if you have to explicitly declare interfaces.

When discussing putting something like this in Gosu, the main disadvantage we came up with was around tooling. Probably not a big issue for Go, given that I haven't really heard of too much focus on IDE/refactoring tooling there, but if one were to implement such tools, the implicit interfaces make things a bit harder. For example, if I have a Nameable interface with a getName() method, and 20 classes in my system have a getName() method but only 3 of them are actually used as Nameables, if I want to refactor the getName() method in a system like Java, I'll know which classes explicitly implement Nameable and thus which classes to refactor. In Go, it's a hard problem, because you have to know which classes are ever used as Nameables; that's no longer a property of the class itself, but rather something you have to derive from your code base. It similarly makes IDE functions like "find usages" or "find implementors" much harder to implement. (Technically they're not 100% intractable, but they're certainly much harder to do well.)

Those tooling issues are really the only drawbacks we could come up with, though. Otherwise I think the Go approach is much more flexible than the Java one.

wouldn't a bigger problem be that getName() may refer to getting a Person 's name or an enumeration of the platform or worse. ie. that you use the same names for unrelated functions which can happen and does make a certain amount of sense sometimes.

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.

Reply on news.ycombinator.com