These are chat archives for nelsam/vidar

25th
Apr 2017
Samuel Nelson
@nelsam
Apr 25 2017 15:11
you shouldn't use a pointer to an interface
basic.Theme is a struct, which is why I load it as a pointer
gxui.Theme is an interface, but it doesn't contain all of the information that basic.Theme does - it's missing methods to get many of the theme's colors
interfaces are just a collection of methods, so having a pointer to them is usually (there are a few exceptions) pointless and just gets in your way
most of the time, the data that implements the interface is already a pointer
so the interface itself doesn't need to be a pointer because the data that implements it is
Kvaz1r
@Kvaz1r
Apr 25 2017 18:03
thanks for the explanation I will try. The concepts on interfaces in Go seems hard to me. Not simple understood when it abstracts and when concrete exemplar.
Samuel Nelson
@nelsam
Apr 25 2017 18:04
think of an interface as a declaration of the methods you need
example:
Samuel Nelson
@nelsam
Apr 25 2017 18:12
// RequestDoer is an interface that describes the method(s) we need
// to perform a request.  Notice that the Do method is the same as
// http.Client.Do - this is intentional.  It means that consumers can just
// pass in an http.Client if they want - but they could also pass in a
// custom http client, if they'd like (e.g. if they need to add some headers).
// It also allows us to create a mock RequestDoer for testing purposes.
type RequestDoer interface {
  Do(req *http.Request) (http.Response, error)
}

// CreateUser will create a user using the passed in RequestDoer.  It
// doesn't care about the underlying type, so long as doer has a method
// that implements RequestDoer.  This provides a lot of flexibility to
// anything calling CreateUser.
func CreateUser(doer RequestDoer, name, password string) (*User, error) {
    req, err := createUserRequest(name, password)
    if err != nil {
        return nil, err
    }
    resp, err := doer.Do(req)
    if err != nil {
        return nil, err
    }
    return user(resp)
}
the interface types are just a way of declaring which methods you require from types you're accepting
there are some other, less common, uses; but this is the one you'll usually be using
most of the time, gxui is using interfaces in a way that makes little sense
there's really no reason for it to be using interfaces that way
but just know that if you're using an interface from gxui, it's never a pointer
Kvaz1r
@Kvaz1r
Apr 25 2017 18:27
This make sense. So it two in one - and concrete object and abstraction with constraints.
Samuel Nelson
@nelsam
Apr 25 2017 18:27
yeah, that's basically it
Kvaz1r
@Kvaz1r
Apr 25 2017 18:28
In c++ no such things =)
Samuel Nelson
@nelsam
Apr 25 2017 18:29
yeah, it's definitely different than anything in C++
it's more like statically typed duck typing from something like python
duck typing = "if it walks like a duck and quacks like a duck, it must be a duck" (i.e. try using it, and if it has all the methods you need, it must be the type you wanted)
with Go, interfaces provide a compile-time check that the types being passed in have all the methods you need
but you shouldn't care whether or not it has a whole bunch of other methods you don't need
in the above example, http.Client has a ton of methods, but we don't need them, so we don't include them in our interface type
the interface type is saying, "as long as the doer can Do a *http.Request, we don't care what it is"
Kvaz1r
@Kvaz1r
Apr 25 2017 18:34
very conveniently
Kvaz1r
@Kvaz1r
Apr 25 2017 18:39
Btw, I replaced *gxui.Container with gxui.Container and example became to work. Now need make correctly addition item to menu.