[
https://issues.apache.org/jira/browse/FLINK-11409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757541#comment-16757541
]
Kezhu Wang commented on FLINK-11409:
------------------------------------
{quote}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.
{quote}
[~dawidwys] It is perfect ok for {{RichProcessFunction}} to be an abstract
class if there is one as long as we have interface version {{ProcessFunction}}.
Abstract class is not a good candidate in java to encourage callback like api
usage, in this case abstract {{ProcessFunction}} *force* subclass to not
inherit from other branch. The keypoint is that interfaces are composable while
classes are intrusive.
[~aljoscha] I saw this in {{ProcessWindowFunction.Context}} which captures
generic type {{W}} from enclosing class. I think this would not be a big issue
if we have {{ProcessWindowFunction}} as interface from day one. Actually,
{{SourceFunction.Context<T>}} is an interface. I think compatibility plays more
significant than this as I said that "compatibility is still a big
consideration to evaluate this proposal".
Any way, it is perfect ok to not accept this proposal, after all, compatibility
is a big concern.
> 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)
