I've built a simple resource pool with the intention of using it to pool
connections to an as of yet undecided database store for various hobby
projects. It provided a good first exercise, but I need to be a bit more
secure with my grasp of go before I start building out too much the wrong
way ;)
I've got a few questions before I go on to the next component - here's the
pool: https://github.com/jkassemi/pool.go
1. The pool constructor, NewPool, returns a new Pool struct that's been
initialized with the correct channel. I can't find it now, but I recalled
reading somewhere in the documentation that you should be able to use make
to initialize a new struct and just expect that struct to be usable at that
point. Is there a better way of writing this without using the constructor
function? Should interfaces to this system create their own channel?
2. On line 26 of pool_test.go, there's a type assertion on the return,
since the channel returns an untyped interface pointer - I looked into
using reflect to determine the type of interface sent to the channel,
storing the type in a separate struct, etc, but don't have a good method of
returning the same type to the calling code. Is there a graceful way to
handle this and return the same type from the interface?
3. My first iteration of the pool system didn't use buffered channels,
and was a bit larger in scope. When I introduced the channels to this
system the library shrunk dramatically. In a typical go project would it be
better to implement the pool within the library requiring it, or is this a
pattern worth extracting?
4. Github/Bitbucket/Google Code - is there a service that's clearly
beginning to dominate that I should be using or at least becoming more
familiar with?
If you would be willing to put in the time to tear this library down line
by line to recommend better practices in the future (documentation,
testing, benchmarks , style and examples), I'd really appreciate it, and
will happily return the favor.
Thanks!
--
