4 ms·

If Go gets generics, maybe they’ll actually add an ‘implements’ keyword for interfaces and no more of this: var _ SomeIface = SomeConcrete{} var _ AnotherI

If Go gets generics, maybe they’ll actually add an ‘implements’ keyword for interfaces and no more of this: var _ SomeIface = SomeConcrete{} var _ AnotherIface = SomeConcrete{} Just to see if you actually implemented all the signatures on the interface correctly.

cyphar 8y ago
Actually one of the main benefits of Go over Java is the lack of a requirement for "implements" because otherwise it means that you cannot use a type in a context where the original developer did not intend it to be used (though I imagine you're implying that it would not be required). However quite a few Go developers now use interfaces with an unexported method specifically to stop users from misusing their types in a context they didn't intend. I guess it's come full circle.
- deleted 8y ago
  [deleted]
- artursapek 8y ago
  > However quite a few Go developers now use interfaces with an unexported method specifically to stop users from misusing their types in a context they didn't intend. I guess it's come full circle. What a horrible hack. Why bother with that? Either export your interface, your don't.
  - cyphar 8y ago
    Well -- what if you have multiple implementations of an interface and you want users to be able to choose between them (or rather, you want them to be able to write functions around your interfaces)? I don't really like it much either, but it's a completely valid usecase for unexported methods. In fact I'm pretty sure this was an example from the language developers for why you can have unexported interface methods in Go.
    - burntsushi 8y ago
      > In fact I'm pretty sure this was an example from the language developers for why you can have unexported interface methods in Go. Indeed. It's used in the standard library for describing Go's AST if I recall correctly.
dagss 8y ago
Go has a lot of pain points but the one positive thing it has over other languages is how it handles interfaces. The whole point is that the caller can make new interfaces to fit existing structs in other libraries.
- pjmlp 8y ago
  Nothing new, ML derived languages also allow for it.
  - k__ 8y ago
    TypeScript too.
  - deleted 8y ago
    [deleted]
- jonathankoren 8y ago
  Actually, two of the pain points of Go is not knowing exactly what interfaces a class implements, and finding out that you misimplemented an interface but not discover this static analysis until you get a runtime type check failure. All this pain for what boils down to not having to make a wrapper. Sure wrappers are dumb, but pushing a static analysis out to a run time error dumber, especially since implementing interfaces is a lot more common than wrapping 3rd party structs.
- stouset 8y ago
  Implicit implementation of interfaces is a disjoint concept from allowing third-party users to implement new interfaces on first-party or second-party structs. The latter is wonderful, and other languages support this without needing to resort to the former.

cyphar 8y ago

Actually one of the main benefits of Go over Java is the lack of a requirement for "implements" because otherwise it means that you cannot use a type in a context where the original developer did not intend it to be used (though I imagine you're implying that it would not be required). However quite a few Go developers now use interfaces with an unexported method specifically to stop users from misusing their types in a context they didn't intend. I guess it's come full circle.

deleted 8y ago
[deleted]
artursapek 8y ago
> However quite a few Go developers now use interfaces with an unexported method specifically to stop users from misusing their types in a context they didn't intend. I guess it's come full circle. What a horrible hack. Why bother with that? Either export your interface, your don't.
- cyphar 8y ago
  Well -- what if you have multiple implementations of an interface and you want users to be able to choose between them (or rather, you want them to be able to write functions around your interfaces)? I don't really like it much either, but it's a completely valid usecase for unexported methods. In fact I'm pretty sure this was an example from the language developers for why you can have unexported interface methods in Go.
  - burntsushi 8y ago
    > In fact I'm pretty sure this was an example from the language developers for why you can have unexported interface methods in Go. Indeed. It's used in the standard library for describing Go's AST if I recall correctly.

dagss 8y ago

Go has a lot of pain points but the one positive thing it has over other languages is how it handles interfaces. The whole point is that the caller can make new interfaces to fit existing structs in other libraries.

pjmlp 8y ago
Nothing new, ML derived languages also allow for it.
- k__ 8y ago
  TypeScript too.
- deleted 8y ago
  [deleted]
jonathankoren 8y ago
Actually, two of the pain points of Go is not knowing exactly what interfaces a class implements, and finding out that you misimplemented an interface but not discover this static analysis until you get a runtime type check failure. All this pain for what boils down to not having to make a wrapper. Sure wrappers are dumb, but pushing a static analysis out to a run time error dumber, especially since implementing interfaces is a lot more common than wrapping 3rd party structs.
stouset 8y ago
Implicit implementation of interfaces is a disjoint concept from allowing third-party users to implement new interfaces on first-party or second-party structs. The latter is wonderful, and other languages support this without needing to resort to the former.