4 ms·
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
by 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.