You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beam.apache.org by Kenneth Knowles <kl...@google.com.INVALID> on 2017/02/03 19:03:01 UTC
[PROPOSAL] New way of passing lambdas
Hi all,
Right now when you want to use MapElements<A, B> (and friends) you have two
options:
1. Use a SimpleFunction Java 7 style
MapElements.via(SimpleFunction<A, B>() {
@Override
public B return apply(A input) {
return ...expr...;
}
}
and the type descriptors are automatically inferred
2. Use a lambda and withOutputType
MapElements.via((A input) -> ...expr...)
.withOutputType(new TypeDescriptor<B>(){})
MapElements.via((A input) -> ...expr...)
.withOutputType(TypeDescriotors.bs())
and you might have a handy helper in TypeDescriptors (note the plural) or
you might have to create your own, which is a weird pattern if you haven't
seen it before. Both shown above.
[PROPOSAL] Here is a neat trick for getting type information like in #1 but
with a lambda like #2 and a bit less verbosity:
MapElements.via(new SimpleFunction<A, B>((A input) -> ...expr...) {})
I think we can add this. I lean towards this just being a third option, but
could be easily swayed to drop #2.
This is https://github.com/apache/beam/pull/1855 where you can see some
unit tests demonstrating it more, and take a look at what it means for
error checking, etc. It is backwards-compatible but still a change to a
core API so deserves a thread on list.
Thoughts?
Kenn
Re: [PROPOSAL] New way of passing lambdas
Posted by Jesse Anderson <je...@smokinghand.com>.
Excellent! On the redefinition of #2, people are used to it. With Hadoop
MapReduce, you had to define types in 1-3 different places.
While you're there, we also need also need a lambda that has access to the
Context object.
On Fri, Feb 3, 2017 at 11:03 AM Kenneth Knowles <kl...@google.com.invalid>
wrote:
> Hi all,
>
> Right now when you want to use MapElements<A, B> (and friends) you have two
> options:
>
> 1. Use a SimpleFunction Java 7 style
>
> MapElements.via(SimpleFunction<A, B>() {
> @Override
> public B return apply(A input) {
> return ...expr...;
> }
> }
>
> and the type descriptors are automatically inferred
>
> 2. Use a lambda and withOutputType
>
> MapElements.via((A input) -> ...expr...)
> .withOutputType(new TypeDescriptor<B>(){})
>
> MapElements.via((A input) -> ...expr...)
> .withOutputType(TypeDescriotors.bs())
>
> and you might have a handy helper in TypeDescriptors (note the plural) or
> you might have to create your own, which is a weird pattern if you haven't
> seen it before. Both shown above.
>
> [PROPOSAL] Here is a neat trick for getting type information like in #1 but
> with a lambda like #2 and a bit less verbosity:
>
> MapElements.via(new SimpleFunction<A, B>((A input) -> ...expr...) {})
>
> I think we can add this. I lean towards this just being a third option, but
> could be easily swayed to drop #2.
>
> This is https://github.com/apache/beam/pull/1855 where you can see some
> unit tests demonstrating it more, and take a look at what it means for
> error checking, etc. It is backwards-compatible but still a change to a
> core API so deserves a thread on list.
>
> Thoughts?
>
> Kenn
>
Re: [PROPOSAL] New way of passing lambdas
Posted by Aljoscha Krettek <al...@apache.org>.
I also like the new way but for some people it might seem weird that they
have to wrap their lambda in an anonymous inner class instantiation.
Maybe we should add it as an additional way and see how it turns out.
On Sat, 4 Feb 2017 at 17:55 Amit Sela <am...@gmail.com> wrote:
> +1 that does look better than using TypeDescriptors, and I would not drop
> APIs yet.. let's give it some time.
>
> On Sat, Feb 4, 2017 at 11:54 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
> > +1 with the proposal. Very good initiative !
> >
> > Thanks
> > Regards
> > JB
> >
> > On Feb 3, 2017, 15:03, at 15:03, Kenneth Knowles <klk@google.com.INVALID
> >
> > wrote:
> > >Hi all,
> > >
> > >Right now when you want to use MapElements<A, B> (and friends) you have
> > >two
> > >options:
> > >
> > >1. Use a SimpleFunction Java 7 style
> > >
> > > MapElements.via(SimpleFunction<A, B>() {
> > > @Override
> > > public B return apply(A input) {
> > > return ...expr...;
> > > }
> > > }
> > >
> > >and the type descriptors are automatically inferred
> > >
> > >2. Use a lambda and withOutputType
> > >
> > > MapElements.via((A input) -> ...expr...)
> > > .withOutputType(new TypeDescriptor<B>(){})
> > >
> > > MapElements.via((A input) -> ...expr...)
> > > .withOutputType(TypeDescriotors.bs())
> > >
> > >and you might have a handy helper in TypeDescriptors (note the plural)
> > >or
> > >you might have to create your own, which is a weird pattern if you
> > >haven't
> > >seen it before. Both shown above.
> > >
> > >[PROPOSAL] Here is a neat trick for getting type information like in #1
> > >but
> > >with a lambda like #2 and a bit less verbosity:
> > >
> > > MapElements.via(new SimpleFunction<A, B>((A input) -> ...expr...) {})
> > >
> > >I think we can add this. I lean towards this just being a third option,
> > >but
> > >could be easily swayed to drop #2.
> > >
> > >This is https://github.com/apache/beam/pull/1855 where you can see some
> > >unit tests demonstrating it more, and take a look at what it means for
> > >error checking, etc. It is backwards-compatible but still a change to a
> > >core API so deserves a thread on list.
> > >
> > >Thoughts?
> > >
> > >Kenn
> >
>
Re: [PROPOSAL] New way of passing lambdas
Posted by Amit Sela <am...@gmail.com>.
+1 that does look better than using TypeDescriptors, and I would not drop
APIs yet.. let's give it some time.
On Sat, Feb 4, 2017 at 11:54 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> +1 with the proposal. Very good initiative !
>
> Thanks
> Regards
> JB
>
> On Feb 3, 2017, 15:03, at 15:03, Kenneth Knowles <kl...@google.com.INVALID>
> wrote:
> >Hi all,
> >
> >Right now when you want to use MapElements<A, B> (and friends) you have
> >two
> >options:
> >
> >1. Use a SimpleFunction Java 7 style
> >
> > MapElements.via(SimpleFunction<A, B>() {
> > @Override
> > public B return apply(A input) {
> > return ...expr...;
> > }
> > }
> >
> >and the type descriptors are automatically inferred
> >
> >2. Use a lambda and withOutputType
> >
> > MapElements.via((A input) -> ...expr...)
> > .withOutputType(new TypeDescriptor<B>(){})
> >
> > MapElements.via((A input) -> ...expr...)
> > .withOutputType(TypeDescriotors.bs())
> >
> >and you might have a handy helper in TypeDescriptors (note the plural)
> >or
> >you might have to create your own, which is a weird pattern if you
> >haven't
> >seen it before. Both shown above.
> >
> >[PROPOSAL] Here is a neat trick for getting type information like in #1
> >but
> >with a lambda like #2 and a bit less verbosity:
> >
> > MapElements.via(new SimpleFunction<A, B>((A input) -> ...expr...) {})
> >
> >I think we can add this. I lean towards this just being a third option,
> >but
> >could be easily swayed to drop #2.
> >
> >This is https://github.com/apache/beam/pull/1855 where you can see some
> >unit tests demonstrating it more, and take a look at what it means for
> >error checking, etc. It is backwards-compatible but still a change to a
> >core API so deserves a thread on list.
> >
> >Thoughts?
> >
> >Kenn
>
Re: [PROPOSAL] New way of passing lambdas
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
+1 with the proposal. Very good initiative !
Thanks
Regards
JB\u2063\u200b
On Feb 3, 2017, 15:03, at 15:03, Kenneth Knowles <kl...@google.com.INVALID> wrote:
>Hi all,
>
>Right now when you want to use MapElements<A, B> (and friends) you have
>two
>options:
>
>1. Use a SimpleFunction Java 7 style
>
> MapElements.via(SimpleFunction<A, B>() {
> @Override
> public B return apply(A input) {
> return ...expr...;
> }
> }
>
>and the type descriptors are automatically inferred
>
>2. Use a lambda and withOutputType
>
> MapElements.via((A input) -> ...expr...)
> .withOutputType(new TypeDescriptor<B>(){})
>
> MapElements.via((A input) -> ...expr...)
> .withOutputType(TypeDescriotors.bs())
>
>and you might have a handy helper in TypeDescriptors (note the plural)
>or
>you might have to create your own, which is a weird pattern if you
>haven't
>seen it before. Both shown above.
>
>[PROPOSAL] Here is a neat trick for getting type information like in #1
>but
>with a lambda like #2 and a bit less verbosity:
>
> MapElements.via(new SimpleFunction<A, B>((A input) -> ...expr...) {})
>
>I think we can add this. I lean towards this just being a third option,
>but
>could be easily swayed to drop #2.
>
>This is https://github.com/apache/beam/pull/1855 where you can see some
>unit tests demonstrating it more, and take a look at what it means for
>error checking, etc. It is backwards-compatible but still a change to a
>core API so deserves a thread on list.
>
>Thoughts?
>
>Kenn