fatih/set — pull request #8 by sdboyer (2014-01-16 00:08:48+00:00)
Title: Introduce Set interface & Each method

so, this is a little prep work, leading up to the goal of #7.

i've created a Set interface, and refactored the methods in the package to specify that, instead of `*Set`, as the type for provided parameters, and the return value in most cases. the side effect of doing this is that it's no longer OK to reach in and lock the mutexes in the provided object, as there's no guarantee that it's there. it seems this is the desired behavior if we're going to have a non-threadsafe set; one ought to be able to mix and match the two, no?

the bigger issue, though, is that it's not really possible any longer to directly reach in and `for...range` across the map storage of the passed set. to that end, i've introduced an `Each()` method, which is really just an iterator achieved via injecting a closure. (i think that's a useful addition, regardless). that's now used to do these traversals; the performance hit, based on the benchmarks introduced here, looks to be around 5%:

```
Through Each() (new):
BenchmarkSetEquality	10000	767576 ns/op
BenchmarkSubset	10000	786049 ns/op

Direct map iteration (old):
BenchmarkSetEquality	10000	723936 ns/op
BenchmarkSubset	10000	728652 ns/op
```
i also profiled this a bit, mostly just out of curiousity - results are here: https://gist.github.com/sdboyer/8447255 . that's profiling the `BenchmarkSetEquality` test. from that...well, i'm not even sure "from that". but hey, there it is :)

bottom line - i thought we'd discuss whether or not you're OK with these changes before i proceed on to implementing the non-ts set. if so, the next step from here is fairly obvious, but i wanted to check in first.

also, side question - is there a reason you bookend the set methods with the lock/unlock calls instead of using `defer s.RUnlock()` up top, immediately after acquiring the lock?