I could be wrong about this but I think it would be more usable if the apply methods took N Tuple2 parameters instead of a single TupleN[Tuple2...]. As a practical matter, that means you wouldn't need the extra set of parens and constructing a MapAggregator would look almost exactly like constructing a Map: MapAggregator("min" -> Aggregator.min, "max" -> Aggregator.max).

+1 to Avi's suggestion. Also, not that it is super important: but are you planning to use this or is it just a nice generalization? The reason I ask is that I'm surprised that the result type (V is the map) is homogenous across a wide variety of aggregations. Of course, Double might be common enough.

Yeah, Double is quite common for us. Also, you can imagine using an Either type or something similar (like brushfire's 4-way Dispatched) to unify disparate aggregation results into a single V.

Totally convinced, made the suggested changes! cc @mlmanapat

Thanks, @DanielleSucher!

For consistency/simplicity-of-use, we're missing the ability to generate Tuple or Map aggregator from one entry...

at the moment we'he hacked up this:

  /**
   * makes an aggregator returning a Tuple1[Metric]
   * this allows to keep aggregator definition consistent with GeneratedTupleAggregator.fromN
   */
  def tupleAggrFrom1[A, B, C](agg: Aggregator[A, B, C]): Aggregator[A, B, scala.Tuple1[C]] = {
    agg.andThenPresent(Tuple1(_))
  }

  // for the MapAggregator
  def mapAggrFrom1[A, B, C <: AnyVal](aggDef: (String, Aggregator[A, B, C])): Aggregator[A, B, Map[String, AnyVal]] = {
    val (key, agg) = aggDef
    agg.andThenPresent(value => Map(key -> value))
  }

it would be nice to have these methods in algebird too :)