@rubyist brings up a good point that the Lot type, being sent down to clients of
the `Batcher` type, introduces some complexity in that clients must know how
`Lot`s work. I don't think the `Lot` type gives a clear enough advantage to
warrant the added complexity for clients.
This commit drops the `Lot` type for operations directly on `[]Transferable`,
but keeps some of the refactors from earlier in PR #615.
This commit removes an ambiguity in the signature of the IsFull function on the
Lot type. Since the IsFull method has to do with checking the length of the
underlying slice, it seemed more appropriate to call the argument something to
do with length, rather than capacity.
This commit introduces several refactorings to the `run` method (now called
`acceptInput`) on the Batcher type, and introduces the type `Lot`.
- A call to `acceptInput` directly does not spawn a goroutine. The recommended
way to initialize is to spawn it as a goroutine, which is how the constructor
method handles initialization of the Batcher type.
- The responsibility of creating new batches is pushed down into the `newBatch`
func, which allocates a slice of `Transferable`s and sets its capacity at the
maximum batch size by calling into the NewLot constructor func.
- The Lot type lets us make use of several convenience methods by wrapping the
[]Transferable type. Pushed out the responsibility of checking whether a given
"batch" (now Lot) is full. Also delegates the responsibility of Lot allocation
et. al. further down.
