Re: [incquery-dev] IPatternMatch refactoring

[Ábel Hegedüs <abel.hegedus@xxxxxxxxxx>]

Hi, 

thanks Gaben for the quite detailed and not as quick&dirty analysis as I first expected!

- Fortunately, the decoupling of RuleSpecification from MatcherFactory was already done earlier, so only the change from Activation<IPatternMatch> and RuleSpecification<IPatternMatch> to ITuple versions is required. After that it is possible to define specific RuleSpecifications, which attach to an event source when instantiating.

- Also, EVM uses isCompatibleWith and isMutable at the moment for checking filter, so that's also covered.

- The EVM Job accepts Activations, not Matches, the _specific_ versions, e.g. StatelessJob uses IMatchProcessor, and renaming it to StatelessPatternMatchJob can prevent any misunderstandings.

- Finally, RuleInstance uses IMatchProcessor and IMatchUpdateListener for attaching to the event source, but that can be refactored into the IncQueryMatcher-specific RuleInstance class.

Concerning the source of the discussion, my other suggestion was to build the EventPattern concept by extending the patternlanguage of EMF-IncQuery, but I understand that on the one hand it may be cumbersome, on the other hand, it is better to avoid the confusion when someone tries to create a matcher for an EventPattern in an IncQueryEngine and the engine drops dead.

Cheers,

   Ábel Hegedüs

Fault Tolerant Systems Research Group
Department of Measurement and Information Systems
Budapest University of Technology and Economics

On 18 April 2013 11:09, <bergmann@xxxxxxxxxx> wrote:

Hi,

-----incquery-dev-bounces@xxxxxxxxxxx ezt írta: -----

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

I don't like this hack.

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

What do you really need in the common interface? Mapping positions and parameter names to value objects? 

How about ITuple?

>I find option B much more appropriate. 

I agree, but I also share the other István's concern about ripple effects.

An initial & superficial & quick & dirty change impact analysis:

 - ITuple and BaseTuple should extract parameterNames(), getters, setters, isMutable(), toArray(), prettyPrint(), isCompatibleWith() and most importantly the semantics.

 - ITuple needs a "schema", which is the pattern in case of IPatternMatch, and ComplexEventDefinition or whatever in your case. This is schema required, at the very least, for comparison in equals(). The type-safe alias pattern() should remain in IPatternMatch.

 - ITupleProcessor superinterface for IMatchProcessor... or maybe eliminate IMatchProcessor altogether.

 - an EVM Job should accept an ITuple, and the context-free/stateless version should be constructible for an ITupleProcessor of the right tuple type

 - Activation should associate with an ITuple

 - and the most difficult part: associating RuleSpecifications with something (~MatcherFactory) that will be able to hook onto an Engine to create an event source (~Matcher) that will eventually provide events characterized by ITuples of the right type.

For the last part, I think Ábel may provide more insight.

Cheers,

Gaben

_______________________________________________
incquery-dev mailing list
incquery-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/incquery-dev