[
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)
