[go-nuts] Re: the case for returning interface vs struct

2017-03-02 Thread Henry
Hi, Copying struct directly has its problems. As mentioned before, when your struct contains mutexes, maps, arrays, or pointers, you may not want your struct to be shallow-copied. You may initially have a simple struct that can be shallow-copied and it has then been used all over the place.

[go-nuts] Re: the case for returning interface vs struct

2017-03-02 Thread 'Eric Johnson' via golang-nuts
Structs give the caller so many immediate benefits: - If there's internal state that clients shouldn't muck around with, then (a) keep a field private, or (b) keep a field private and make it a pointer to state (such as mutexes). - Structs can be copied directly. - Set and get

Re: [go-nuts] Re: the case for returning interface vs struct

2017-03-01 Thread Henrik Johansson
This comes down to encapsulation I guess. You may want to hide some internals and perhaps not other. Simple data types are probably fine but say that you have an interface Store then you can have redisStore or cassandraStore both implementing the same interface and the rest of your program just

[go-nuts] Re: the case for returning interface vs struct

2017-03-01 Thread Henry
If you simply return unexported data types, there is no way your data users can understand what your data type does since godoc does not document unexported types. On Thursday, March 2, 2017 at 1:27:42 PM UTC+7, Tamás Gulácsi wrote: > > Accept interface (the smallest possible) but return