[jira] [Comment Edited] (FLINK-11409) Make `ProcessFunction`, `ProcessWindowFunction` and etc. pure interfaces

["Dawid Wysakowicz (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FLINK-11409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757323#comment-16757323 ] 

Dawid Wysakowicz edited comment on FLINK-11409 at 1/31/19 3:00 PM:
-------------------------------------------------------------------

Ok, now I see your point, I don't entirely agree though this is the pattern that we use/encourage users to use for {{Rich}} versions, as for {{MapFunction}}, {{FilterFunction}} etc. we have their corresponding {{RichMapFunction}}, {{RichFilterFunction}}.

Now I understand your suggestion I would say I like it in general, as it tries to separate those two (or even more) topics. I'm afraid though the current policy is that we don't break event the {{@PublicEvolving}} contract...


was (Author: dawidwys):
Ok, now I see your point, I don't entirely agree though this the pattern that we use/encourage users to use for {{Rich}} versions, as for {{MapFunction}}, {{FilterFunction}} etc. we have their corresponding {{RichMapFunction}}, {{RichFilterFunction}}.

Now I understand your suggestion I would say I like it in general, as it tries to separate those two (or even more) topics. I'm afraid though the current policy is that we don't break event the {{@PublicEvolving}} contract...

> Make `ProcessFunction`, `ProcessWindowFunction` and etc. pure interfaces
> ------------------------------------------------------------------------
>
>                 Key: FLINK-11409
>                 URL: https://issues.apache.org/jira/browse/FLINK-11409
>             Project: Flink
>          Issue Type: Improvement
>          Components: DataStream API
>            Reporter: Kezhu Wang
>            Assignee: Kezhu Wang
>            Priority: Major
>              Labels: Breaking-Change
>
> I found these functions express no opinionated demands from implementing classes. It would be nice to implement as interfaces not abstract classes as abstract class is intrusive and hampers caller user cases. For example, client can't write an `AbstractFlinkRichFunction` to unify lifecycle management for all data processing functions in easy way.
> I dive history of some of these functions, and find that some functions were converted as abstract class from interface due to default method implementation, such as `ProcessFunction` and `CoProcessFunction` were converted to abstract classes in FLINK-4460 which predate -FLINK-7242-. After -FLINK-7242-, [Java 8 default method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html]
>  would be a better solution.
> I notice also that some functions which are introduced after -FLINK-7242-, such as `ProcessJoinFunction`, are implemented as abstract classes. I think it would be better to establish a well-known principle to guide both api authors and callers of data processing functions.
> Personally, I prefer interface for all exported function callbacks for the reason I express in first paragraph.
> Besides this, with `AbstractRichFunction` and interfaces for data processing functions I think lots of rich data processing functions can be eliminated as they are plain classes extending `AbstractRichFunction` and implementing data processing interfaces, clients can write this in one line code with clear intention of both data processing and lifecycle management.
> Following is a possible incomplete list of data processing functions implemented as abstract classes currently:
>  * `ProcessFunction`, `KeyedProcessFunction`, `CoProcessFunction` and `ProcessJoinFunction`
>  * `ProcessWindowFunction` and `ProcessAllWindowFunction`
>  * `BaseBroadcastProcessFunction`, `BroadcastProcessFunction` and `KeyedBroadcastProcessFunction`
> All above functions are annotated with `@PublicEvolving`, making they interfaces won't break Flink's compatibility guarantee but compatibility is still a big consideration to evaluate this proposal.
> Any thoughts on this proposal ? Please must comment out.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)