Aljoscha Krettek commented on FLINK-3869:

I have another proposal for solving this: I started to dislike how the 
reduce/fold with window function is called {{apply()}}. Yes, You can see the 
apply with incremental aggregation as either an apply that has an additional 
incremental aggregation function or as an incremental aggregation (reduce/fold) 
that has an apply added to it. Right now, I think these two methods should be:
reduce(ReduceFunction, WindowFunction)
fold(Initial, FoldFunction, WindowFunction)

this would make them more discoverable, i.e. you do a reduce and then you see 
that you can also give a {{WindowFunction}} to get all the meta data for the 

If we changed to that new naming scheme we could fix the fold restriction and 
deprecate the old methods, thereby not breaking any existing code.

[~StephanEwen] what do you think?

> WindowedStream.apply with FoldFunction is too restrictive
> ---------------------------------------------------------
>                 Key: FLINK-3869
>                 URL: https://issues.apache.org/jira/browse/FLINK-3869
>             Project: Flink
>          Issue Type: Sub-task
>          Components: Streaming
>            Reporter: Aljoscha Krettek
>            Assignee: Aljoscha Krettek
> Right now we have this signature:
> {code}
> public <R> SingleOutputStreamOperator<R> apply(R initialValue, 
> FoldFunction<T, R> foldFunction, WindowFunction<R, R, K, W> function) {
> {code}
> but we should have this signature to allow users to return a type other than 
> the fold accumulator type from their window function:
> {code}
> public <ACC, R> SingleOutputStreamOperator<R> apply(ACC initialValue, 
> FoldFunction<T, ACC> foldFunction, WindowFunction<ACC, R, K, W> function) {
> {code}

This message was sent by Atlassian JIRA

Reply via email to