OK i will change the algebird pullreq to open up the constructor again then
too


On Mon, Mar 10, 2014 at 2:03 PM, ianoc <notifications@github.com> wrote:

> In algebird-core/src/main/scala/com/twitter/algebird/SpaceSaver.scala:
>
> > @@ -101,7 +101,7 @@ object SSMany {
> >    private def apply[T](capacity: Int, counters: Map[T, (Long, Long)], buckets: SortedMap[Long, Set[T]]): SSMany[T] =
> >      SSMany(capacity, counters, Some(buckets))
> >
> > -  private def apply[T](capacity: Int, counters: Map[T, (Long, Long)]): SSMany[T] =
> > +  def apply[T](capacity: Int, counters: Map[T, (Long, Long)]): SSMany[T] =
>
> Thanks for the explanation, very useful. In a streaming compute context
> there can be many merges occurring reduce side. Different cache settings,
> would be coming into play often. Serialization to a store would be
> interesting here, given you would have a longer lived SSMany your merging
> with a newer one to update it... if the rebuilding here would be expensive
> to do the merge I'm certainly in favour of including the field in the
> serialization. -- Just trying to think of this in a context other than
> hadoop.
>
> End users shouldn't be using either SSMany or SSOne directly right? and we
> have apply methods without this arg, so if they create something in an
> invalid state i'm not sure there is too much to be done?
>
> Unless you have a big objection could you use the full set of parms?
>
> --
> Reply to this email directly or view it on GitHub<https://github.com/twitter/algebird/pull/289/files#r10441611>
> .
>