3 ms·
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 metho
by 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