I made some comments on https://issues.apache.org/jira/browse/BEAM-2950
which was filed to do a similar thing for State. Luke correctly pointed out
that many of the points apply here as well. I said most of the same above,
but I thought I'd pull them out again from that ticket and rephrase to
apply to side inputs:

 - Direct access at first appears "more intuitive" because to a newcomer it
"looks like" normal [captured variable] access. But in fact it is nothing
like normal [captured variable] access so this intuition is misleading and
should not be encouraged. So it is actually less readable because your
intuitive reading is wrong.

 - This design would miss the validation aspect. One way it is different
than normal [functional] programming is that there are many places it is
illegal to reference [side inputs], such as StartBundle/FinishBundle, or
passing to another object. This proposal would turn those into dynamic
failures at best, or in the worst case data corruption (runner fails to
catch illegal access, and permits some thread-global context to leak)

 - It is actually mandatory that we are always able to detect [side inputs,
or the user has to manually wire them], as it [must be scheduled
differently]

 - A runner can't automatically prefetch, because it doesn't know which
[side input] is used by which methods.

 - Magic by mutating stuff into place is just less readable / more error
prone.

State has even more compelling issues and none of the benefits so my +0.75
for side inputs (now I am feeling more like +0.25) is a -1 for state. We
should definitely not block one feature on all vaguely similar features.

Kenn

On Wed, Sep 13, 2017 at 1:56 PM, Eugene Kirpichov <
[EMAIL PROTECTED]lid> wrote:
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB