+1
> On Apr 11, 2017, at 5:34 PM, Thomas Groh <[email protected]> wrote: > > 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 >>
