What do you think about something like:
env.fromElements(1, 2, 3)
.flatMap((Integer i, Collector<Integer> o) ->
o.collect(i)).returns("Integer")
.print();
This looks to me like the most readable and user-friendly solution. We
only need to change the internals of DataSet a little bit, such that a
possible TypeExtractor Exception is stored temporarily and thrown by the
operator that follows if "returns()" was not called.
Regards,
Timo
On 28.10.2014 15:34, Stephan Ewen wrote:
Is it possible to use a static method "hint" to create the hinting wrapper
function?
Something like
DataSet.map(hint( (x) -> x.toString() , String.class));
If we go for option (1), I would suggest to call the methods just "from"
and overload them for String, Class, and TypeInformation
Stephan
On Tue, Oct 28, 2014 at 3:27 PM, Timo Walther <fl...@twalthr.com> wrote:
Hi all,
currently the Eclipse JDT compiler was the only compiler that included
generic signatures for Lambda Expressions in class files which is necessary
to use them type-safe in Flink. Unfortunalely, this "feature" was
considered as a "bug" and had been thrown out with Eclipse 4.4.1. This is
why Lambdas do not work properly with the current version of Eclipse. I
have opened a bug for that (see https://bugs.eclipse.org/bugs/
show_bug.cgi?id=449063).
The question is: Independent of the decision of the Eclipse JDT team, how
do we want to deal with missing return type information?
Option 1)
Add a separate TypeInformation argument to each Java API operator. Leads
to blown up API...
.map((x)->x + 1, TypeInformation.fromString("Integer"))
.flatMap((in, out)->out.collect(in), TypeInformation.fromClass(
Integer.class))
Option 2)
Introduce a wrapper class which implements ResultTypeQueryable. Leads to
complicated syntax...
.map(TypeHint.map((x)->x + 1, "Integer"));
.map(TypeHint.map((x)->x + 1, Integer.class));
What are your opinions? Or any other ideas?
Regards,
Timo
