Re: [incquery-dev] IPatternMatch refactoring

[Istvan Rath <rath@xxxxxxxxxx>]

Hi István,

While I'm generally in favour of the idea (in my opinion, if we go for a refactoring, then definitely option B would be the choice), I have some doubts about the benefits vs. the amount of work required to make this happen nicely. 

It would be helpful if you could give a more thorough and justified explanation why such a refactoring is beneficial:

- Is there a functional reason (perhaps in the EVM API) that would explain why IEventPatternMatch and IPatternMatch need to be connected somehow? To what extent would option B trigger changes in the code of the EVM? What would be the implications if there is no connection between IPatternMatch and IEventPatternMatch (perhaps duplication of code)?

- If we go for option B, would anything else from the current IncQuery API (e.g. Matcher, MatchProcessor, …) need to be generalized and refactored too?

- Is there a use case (maybe outside of the EVM) where the suggested commonality (IMatch, ...) could be exploited?

If we do things properly, refactoring IPatternMatch to a more abstract IMatch (and its ripple effects) would probably imply the creation of a new component (as, I presume, IMatch should be conceptually not tied to graph pattern matching and not have dependencies on IncQuery's pattern language). This in turn would necessitate a change in the overall internal architecture and dependency network - not minor changes for sure.

cheers

István

On Wednesday, April 17, 2013 at 10:24 PM, Dávid István wrote:

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.)

--

Istvan RATH, PhD

Research fellow
Budapest University of Technology and Economics

Fault Tolerant Systems Research Group