5 ms·

That was my initial struggle as well coming into Go (I have worked for several years in C# & Java). You learn to work around this limitation using interfaces f

by venuzr 13y ago

That was my initial struggle as well coming into Go (I have worked for several years in C# & Java). You learn to work around this limitation using interfaces for both function parameters and return types. Frankly, I have had to do a little more explicit typecasting that I would have liked (going from interfaces to the actual type) but it is ok.

alok-g 13y ago
Are you saying that making sure the type is correct (just before the cast) becomes the programmer's responsibility? How often does this happen?
- quarterto 13y ago
  This is called a type assertion in Go. Whenever you ask for something as an interface but want to use the type's own method, you have to make a type assertion. interface Fooer { func Foo() } type Bar struct {} func (s Bar) Foo() {} func (s Bar) Baz() {} func DoFoo(f Fooer) { f.Foo() // fine // f.Baz() compile error f.(Bar).Baz() // fine }
  - grey-area 13y ago
    Isn't the entire point of an interface to communicate the behaviour expected by the function though? If you want a Bar specifically (as the DoFoo code does above), it should take a Bar as an argument. If you want to accept any struct that satisfies Fooer, add all the methods to Fooer that you need them to satisfy... Doing otherwise is just subverting the type system and you might as well use a blank interface and effectively have no type checking on your input - if you require a Fooer and then typecast someone might pass a Fooer and get a nasty surprise when it doesn't work.
- venuzr 13y ago
  Nope. This mostly becomes a problem if you like to be DRY and try to replace generics (type T) kind of functionality with interfaces. For e.g., I have a method, which does the classic, lookup from cache first before hitting the actual db. In C#, you can use public T Get<T>(int id, string cacheKey) { } When I consume it and say Get for User object, I expect an User object as I already know it's type. In Go, you have to return an interface (and ideally an error) Here would be the equivalent, v, err := s.Get(id int, cacheKey string) if err != nil { //Handle error here } if v == nil || v.(*models.User) == nil { return nil, http.StatusNotFound } Its a bit more code, but on the flip side, it gets you thinking as a client of all the things that can go wrong with your code
grey-area 13y ago
Isn't the idea behind interfaces that you add whatever methods you need to use to the interface? If that's the case you don't need or want to cast, you can just assume that the object given to you conforms to that interface...

by venuzr 13y ago

alok-g 13y ago

Are you saying that making sure the type is correct (just before the cast) becomes the programmer's responsibility? How often does this happen?

quarterto 13y ago
This is called a type assertion in Go. Whenever you ask for something as an interface but want to use the type's own method, you have to make a type assertion. interface Fooer { func Foo() } type Bar struct {} func (s Bar) Foo() {} func (s Bar) Baz() {} func DoFoo(f Fooer) { f.Foo() // fine // f.Baz() compile error f.(Bar).Baz() // fine }
- grey-area 13y ago
  Isn't the entire point of an interface to communicate the behaviour expected by the function though? If you want a Bar specifically (as the DoFoo code does above), it should take a Bar as an argument. If you want to accept any struct that satisfies Fooer, add all the methods to Fooer that you need them to satisfy... Doing otherwise is just subverting the type system and you might as well use a blank interface and effectively have no type checking on your input - if you require a Fooer and then typecast someone might pass a Fooer and get a nasty surprise when it doesn't work.
venuzr 13y ago
Nope. This mostly becomes a problem if you like to be DRY and try to replace generics (type T) kind of functionality with interfaces. For e.g., I have a method, which does the classic, lookup from cache first before hitting the actual db. In C#, you can use public T Get<T>(int id, string cacheKey) { } When I consume it and say Get for User object, I expect an User object as I already know it's type. In Go, you have to return an interface (and ideally an error) Here would be the equivalent, v, err := s.Get(id int, cacheKey string) if err != nil { //Handle error here } if v == nil || v.(*models.User) == nil { return nil, http.StatusNotFound } Its a bit more code, but on the flip side, it gets you thinking as a client of all the things that can go wrong with your code

grey-area 13y ago

Isn't the idea behind interfaces that you add whatever methods you need to use to the interface? If that's the case you don't need or want to cast, you can just assume that the object given to you conforms to that interface...