I was about to comment the same. Generally the CombineFns are more composable units than the global and per-key wrappings; it's not clear why we favor the latter for some Combiners.
On Thu, Dec 22, 2016 at 9:59 AM, Ben Chambers <bchamb...@apache.org> wrote: > Don't they need to be visible for use with composed combine and combining > value state? > > On Thu, Dec 22, 2016, 9:45 AM Lukasz Cwik <lc...@google.com.invalid> wrote: > >> Those are used internally within Sum and its expected that users instead >> call Sum.integersPerKey, or Sum.doublesPerKey, or Sum.integersGlobally, or >> ... >> The Combine.java example specifically calls out using Sum.SumIntegerFn >> instead of calling Sum.integersPerKey. >> >> I filed https://issues.apache.org/jira/browse/BEAM-1208 to address the >> visibility of Sum.[*]Fn instances. >> >> On Thu, Dec 22, 2016 at 3:07 AM, Stas Levin <stasle...@gmail.com> wrote: >> >> > Hi all, >> > >> > I was wondering if there was a reason Sum.SumDoubleFn, SumIntegerFn and >> > SumLongFn are not using the X.of() or X.from() or other instance creation >> > via static method patterns that are so common in Beam? >> > >> > For example: >> > >> > new Sum.SumLongFn() >> > >> > vs. >> > >> > SumFn.ofLong() >> > >> > >> > Regards, >> > Stas >> > >>
