Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[incquery-dev] IPatternMatch refactoring

Hi guys,

As far as i know there's been an API refactoring going on recently; I have a question/request regarding this.

I'm currently implementing the CEP layer for the EVM which will enable defining event patterns (EventPattern) over EMF models and executable actions in case of a match (using an appropriate implementation of the IPatternMatchProcessor interface). As you might see, this is analogous to the concepts of Patterns and IPatternMatches. That's why I'd like to define an IEventPatternMatch interface, which could be processed by the EVM. Extending the IPatternMatch interface would be fine, however I need the pattern() method to return an EventPattern instead of a Pattern. (The latter concept isn't defined in the CEP layer; there are only event patterns.)

Now there are two options here:

A) IEventPatternMatch extends IPatternMatch, it also defines the appropriate eventPattern() method and the inherited pattern() method will return a null value and becomes deprecated.

B) The IPatternMatch gets refactored into a more generic interface (e.g. IMatch) by omitting the method pattern(); the latter interface will be extended by the IPatternMatch and the IEventPatternMatch by the appropriate method(s).

I find option B much more appropriate. Of course, I could put a specialization relation between EventPattern and Pattern and assume that eventually all the inherited methods will prove meaningful and useful for event patterns as well, but given the level of maturity of the CEP project, I'd rather avoid that and wouldn't force any design decisions.

What do you think about this? (Especially Gabor, as he's the author if the corresponding implementation.)

Thanks,
Istvan

Back to the top