Kezhu Wang created FLINK-11409:
----------------------------------
Summary: Make `ProcessFunction`, `ProcessWindowFunction` and etc.
pure interfaces
Key: FLINK-11409
URL: https://issues.apache.org/jira/browse/FLINK-11409
Project: Flink
Issue Type: Improvement
Reporter: Kezhu Wang
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-7274. After
FLINK-7274, [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-7274, 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)
