[ansible]

OK, now I understand. It may be possible to muck things up if you've got two different types (from different packages) that have the exact same signatures for all the functions defined in the interfaces.

It doesn't seem like a high probability that this would happen on accident, though it might be possible to contrive an example.

I'll have to think about that.

[dllthomas]

Certainly the larger an interface is, the less likely that someone supports all of it by accident. Of course, that's both good and bad - if the accidental support would have been correct then we're missing out, but I think most of the time we shouldn't count on that.

One could possibly force the issue by including an unused function with a deliberately unique name (supports_interface_foo, or maybe a UUID or both) as part of the interface. Can functions added later fill parts of interfaces? If so, this approach would make the situation roughly that of Haskell typeclasses. If not, then this approach makes the situation roughly that of Java interfaces. In either case, it might be appropriate to some pickier interfaces.

[AnimalMuppet]

Thinking about it in the abstract, it seems to me that the probability goes up as interfaces get smaller/narrower (which apparently is a style that go encourages) and the codebase gets larger (which is go's target environment).

[dllthomas]

It goes down as method names contain more entropy, too.

[AnimalMuppet]

True. And yet... for a good method name in an interface, you want it to be as general as the interface could be. You want sort(), not sortVector(), because sorting is much more general than sorting a vector - you could sort a tree, if it can be ordered.

You could include the name of the interface as part of the method name, though. But the downside of that approach is, if another interface wants to re-use the same method, things get awkward...