[
https://issues.apache.org/jira/browse/FLINK-11409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kezhu Wang updated FLINK-11409:
-------------------------------
Description:
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.
was:
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-72+42+-. After
-FLINK-72+42+-, [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-72+42+-,
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.
> 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
> 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)
