Factor out moving over loci to an iterator to allow for folds

I wanted to factor out moving over loci for a set of SlidingWindows.  Until now we had only performed a flatMap over loci in a window collecting results at each loci.  I wanted to do two things 1) Factor out the code to move loci by loci over a set of sliding windows and 2) Add some other operations as we move loci by loci, i.e. a fold so we can aggregate data about the reads in order.  I will add some tests for the fold, but wanted to get some feedback earlier on.

cc @timodonnell Might be worth checking out for you if you are looking to get back into guac things.
What if you returned the existing mutable windows but the return type was
the immutable view over them that they inherit from, so that the cast is
free?
On Oct 22, 2014 2:04 PM, "Arun Ahuja" <notifications@github.com> wrote:

> In
> src/main/scala/org/bdgenomics/guacamole/windowing/SlidingWindowIterator.scala:
>
> > @@ -0,0 +1,119 @@
> > +package org.bdgenomics.guacamole.windowing
> > +
> > +import org.bdgenomics.guacamole.{HasReferenceRegion, LociMap}
> > +
> > +/**
> > + *
> > + * This iterator moves locus by locus through a collection of sliding windows.
>
> The other funny case here is the opposite, the consumer tries to collect
> all the windows -
>
> val i = SlidingWindowsIterator(_)val s = i.toSeq
>
> s is a sequence of SlidingWindows that are all the same as opposed to
> what should (I think) be there which is the windows oriented at each locus
> Perhaps it does make sense then to produce and immutable version. One
> downside there is create a small short-lived wrapper, but we can hope the
> GC manages it fine.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/hammerlab/guacamole/pull/189/files#r19232289>.
>