[
https://issues.apache.org/jira/browse/FLINK-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16062863#comment-16062863
]
Dawid Wysakowicz commented on FLINK-3414:
-----------------------------------------
Hi [~kkl0u], [~dian.fu]
As there is ongoing work to introduce GroupPatterns( [FLINK-6927] ) and
branching patterns ( [FLINK-4641] ) I would like to start a discussion about
reworking our Pattern API as a better hierarchical API would help in the
implementation.
I feel there is couple of problems with current API:
# there is lots of places where we throw {{MalformedPatternException}}, it
would be better to restrict illegal patterns in API rather than throw
exceptions in runtime
# API does not corresponds well to hierarchy of groups and branches
# it is hard to provide a good intuitive Scala dsl
In my branch [cep-api-rebuilt|
https://github.com/dawidwys/flink/tree/cep-api-rebuilt ] in {{flink-cep-scala}}
in package {{org.apache.flink.cep.scala.pattern.proto}} I created a proposal
for a new API written in Scala(better type support I think). For this API to
work we would need to port {{NFACompiler.java}} into the new API, which I think
should be done also in Scala, what would allow us to better leverage scala type
support by pattern matching.
As the current API is not annotated as Public, I feel there is no that much of
a problem with breaking API compatibility.
I would love to hear your opinions.
> Add Scala API for CEP's pattern definition
> ------------------------------------------
>
> Key: FLINK-3414
> URL: https://issues.apache.org/jira/browse/FLINK-3414
> Project: Flink
> Issue Type: Improvement
> Components: CEP
> Affects Versions: 1.0.0
> Reporter: Till Rohrmann
> Assignee: Dawid Wysakowicz
> Priority: Minor
>
> Currently, the CEP library only supports a Java API to specify complex event
> patterns. In order to make it a bit less verbose for Scala users, it would be
> nice to also add a Scala API for the CEP library.
> A Scala API would also allow to pass Scala's anonymous functions as filter
> conditions or as a select function, for example, or to use partial functions
> to distinguish between different events.
> Furthermore, the Scala API could be designed to feel a bit more like a DSL:
> {code}
> begin "start" where _.id >= 42 -> "middle_1" as classOf[Subclass] ||
> "middle_2" where _.name equals "foobar" -> "end" where x => x.id <= x.volume
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
