4 ms·

> What do you dislike about them [implicit interfaces]? Implicitly implemented interfaces can lead to problems where you're "implementing" an interface because

by p-e-w 4y ago

> What do you dislike about them [implicit interfaces]? Implicitly implemented interfaces can lead to problems where you're "implementing" an interface because your methods happen to be named the same, but the functionality doesn't adhere to the contract the interface is supposed to represent. Not every contract can be described by the type system, especially not by a type system as limited as Go's. Method names like "Write", "Get", or "Execute" are very common, yet in Go you have to be careful because suddenly you're implementing an interface that is intended for things that have nothing to do with what your code actually does. Simply put, it's an enormous weakening of contract safety, for essentially zero benefit. After all, spelling out that your type implements a certain interface really isn't a lot of work.

cube2222 4y ago
You call it an "enormous weakening of contract safety", I call it an issue I've never once had happen in practice. Sometimes you can't spell out that your type implements a certain interface, because it's not a type controlled by you. Moreover, this completely kills the use-case of "define your own small interface with the subset that you actually require, instead of accepting the whole thing", which is a big part of the value-add. See my other comment[0]. [0]: https://news.ycombinator.com/item?id=33943352 https://news.ycombinator.com/item?id=33943352
- Someone 4y ago
  > Sometimes you can't spell out that your type implements a certain interface, because it's not a type controlled by you. Dynamically inferred interfaces only help there if function names and arguments happen to exactly match those of the interface. So if, for example, a method is called ‘Run’ rather than ‘Execute’, or you have ‘Run(string, int)’ and ‘Run(int, string)’ methods, that won’t work. Some languages that require explicit interfaces (and, I think, most modern ones) allow you to specify that mapping at run time, and also allow you to retroactively make all code (including third party code) that implements FatInterface implement your SmallInterface that’s a subset of it. Golang chooses to not require programmers to do such work and, I think, hopes programmers will keep names and argument type order identical for common methods, so that those problems occur less often. I don’t think that will work in large code bases, but then, I don’t have experience with large golang code bases.
masklinn 4y ago
It also leads to easily fucking up interface implementations because that's not checked, some folks actually put "interface assertions" above the interface methods to ensure they're not forgetting anything and did not screw up any signature e.g. var _ Iface = (*someStruct)(nil) will fail to compile if someStruct does not correctly and fully implement Iface.

by p-e-w 4y ago

cube2222 4y ago

You call it an "enormous weakening of contract safety", I call it an issue I've never once had happen in practice. Sometimes you can't spell out that your type implements a certain interface, because it's not a type controlled by you. Moreover, this completely kills the use-case of "define your own small interface with the subset that you actually require, instead of accepting the whole thing", which is a big part of the value-add. See my other comment[0]. [0]: https://news.ycombinator.com/item?id=33943352 https://news.ycombinator.com/item?id=33943352

Someone 4y ago
> Sometimes you can't spell out that your type implements a certain interface, because it's not a type controlled by you. Dynamically inferred interfaces only help there if function names and arguments happen to exactly match those of the interface. So if, for example, a method is called ‘Run’ rather than ‘Execute’, or you have ‘Run(string, int)’ and ‘Run(int, string)’ methods, that won’t work. Some languages that require explicit interfaces (and, I think, most modern ones) allow you to specify that mapping at run time, and also allow you to retroactively make all code (including third party code) that implements FatInterface implement your SmallInterface that’s a subset of it. Golang chooses to not require programmers to do such work and, I think, hopes programmers will keep names and argument type order identical for common methods, so that those problems occur less often. I don’t think that will work in large code bases, but then, I don’t have experience with large golang code bases.

masklinn 4y ago

It also leads to easily fucking up interface implementations because that's not checked, some folks actually put "interface assertions" above the interface methods to ensure they're not forgetting anything and did not screw up any signature e.g. var _ Iface = (*someStruct)(nil) will fail to compile if someStruct does not correctly and fully implement Iface.