Do you believe it is worth aligning? (That's is, changing the "new"s to static factory methods so as to make their look and feel consistent.)
On Thu, Dec 22, 2016, 21:20 Lukasz Cwik <[email protected]> wrote: > Forgot about the composable combine, closing the JIRA as WAI > > On Thu, Dec 22, 2016 at 10:04 AM, Robert Bradshaw < > [email protected]> wrote: > > > 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 <[email protected]> > > 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 <[email protected]> > > 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 <[email protected]> > > 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 > > >> > > > >> > > >
