3 ms·

> The language has static type-checking. No it does not, at least not completely. When you carry around pointers to struct implementing interfaces, it does not

by shakow 4y ago

> The language has static type-checking. No it does not, at least not completely. When you carry around pointers to struct implementing interfaces, it does not check for anything at compile time. > Or just use any of the popular Go code editors/plugins which give you a "show me all implementations". Does not work all the time, hence my use of the ‶rickety″ adjective. > This makes understanding what a piece of code is doing much easier, while simplifying mocking as well. That's a design problem, not an interface problem. Split you giant 30-methods interface into smaller ones if need be, that the whole point of interfaces: not be a 1-1 mapping to methods, but a semantic (sub)group of them.

foldr 4y ago
>When you carry around pointers to struct implementing interfaces, it does not check for anything at compile time. What exactly do you mean here? You can't assign a value that doesn't implement an interface Foo to a variable of type Foo. That will cause a compile time error.
cube2222 4y ago
> That's a design problem, not an interface problem. Split you giant 30-methods interface into smaller ones if need be, that the whole point of interfaces: not be a 1-1 mapping to methods, but a semantic (sub)group of them. It really isn't. This way it becomes a guessing game "Which methods will be used with which other ones?". Even if I have a KVStore interface with 4 methods: Get, Set, List and Delete, it's a huge value to future code readers if my new structure only accepts an interface with List and Get, or List and Delete. The other commenter already responded to your static typing assertion, so leaving that for there (it absolutely does check it).
- za3faran 4y ago
  > it's a huge value to future code readers if my new structure only accepts an interface with List and Get, or List and Delete. But that's not specific to golang. You can use the same approach in Java, Kotlin, C#, etc
  - cube2222 4y ago
    Unless I'm missing something, you then have to write wrappers that translate between the big and the small interfaces, or explicitly mark all interfaces as implemented at the original type definition point. The first one is a lot of boilerplate, the second one is not always possible.

by shakow 4y ago

foldr 4y ago

>When you carry around pointers to struct implementing interfaces, it does not check for anything at compile time. What exactly do you mean here? You can't assign a value that doesn't implement an interface Foo to a variable of type Foo. That will cause a compile time error.

cube2222 4y ago

> That's a design problem, not an interface problem. Split you giant 30-methods interface into smaller ones if need be, that the whole point of interfaces: not be a 1-1 mapping to methods, but a semantic (sub)group of them. It really isn't. This way it becomes a guessing game "Which methods will be used with which other ones?". Even if I have a KVStore interface with 4 methods: Get, Set, List and Delete, it's a huge value to future code readers if my new structure only accepts an interface with List and Get, or List and Delete. The other commenter already responded to your static typing assertion, so leaving that for there (it absolutely does check it).

za3faran 4y ago
> it's a huge value to future code readers if my new structure only accepts an interface with List and Get, or List and Delete. But that's not specific to golang. You can use the same approach in Java, Kotlin, C#, etc
- cube2222 4y ago
  Unless I'm missing something, you then have to write wrappers that translate between the big and the small interfaces, or explicitly mark all interfaces as implemented at the original type definition point. The first one is a lot of boilerplate, the second one is not always possible.