I think that's a good idea. I would call the outputs of a ParDo the "Main Output" and "Additional Outputs" - it seems like an easy way to make it clear that there's one output that is always expected, and there may be more.
On Tue, Apr 11, 2017 at 5:29 PM, Robert Bradshaw < [email protected]> wrote: > We should do some renaming in Python too. Right now we have > SideOutputValue which I'd propose naming TaggedOutput or something > like that. > > Should the docs change too? > https://beam.apache.org/documentation/programming-guide/#transforms-sideio > > On Tue, Apr 11, 2017 at 5:25 PM, Kenneth Knowles <[email protected]> > wrote: > > +1 ditto about sideInput and sideOutput not actually being related > > > > On Tue, Apr 11, 2017 at 3:52 PM, Robert Bradshaw < > > [email protected]> wrote: > > > >> +1, I think this is a lot clearer. > >> > >> On Tue, Apr 11, 2017 at 2:24 PM, Stephen Sisk <[email protected]> > >> wrote: > >> > strong +1 for changing the name away from sideOutput - the fact that > >> > sideInput and sideOutput are not really related was definitely a > source > >> of > >> > confusion for me when learning beam. > >> > > >> > S > >> > > >> > On Tue, Apr 11, 2017 at 1:56 PM Thomas Groh <[email protected] > > > >> > wrote: > >> > > >> >> Hey everyone: > >> >> > >> >> I'd like to rename DoFn.Context#sideOutput to #output (in the Java > SDK). > >> >> > >> >> Having two methods, both named output, one which takes the "main > output > >> >> type" and one that takes a tag to specify the type more clearly > >> >> communicates the actual behavior - sideOutput isn't a "special" way > to > >> >> output, it's the same as output(T), just to a specified PCollection. > >> This > >> >> will help pipeline authors understand the actual behavior of > outputting > >> to > >> >> a tag, and detangle it from "sideInput", which is a special way to > >> receive > >> >> input. Giving them the same name means that it's not even strange to > >> call > >> >> output and provide the main output type, which is what we want - > it's a > >> >> more specific way to output, but does not have different > restrictions or > >> >> capabilities. > >> >> > >> >> This is also a pretty small change within the SDK - it touches about > 20 > >> >> files, and the changes are pretty automatic. > >> >> > >> >> Thanks, > >> >> > >> >> Thomas > >> >> > >> >
