Re: [incquery-dev] docs update, api refactor ideas, uggested meeting top

[Istvan Rath <rath@xxxxxxxxxx>]

Hi,

On Monday, April 15, 2013 at 10:11 AM, bergmann@xxxxxxxxxx wrote:

I meant getAllMatches() - the version without parameters. 

Similarly, I think we should see at least getOneArbitraryMatch(), hasMatch(), countMatches(), forEachMatch(processor), forOneArbitraryMatch(processor)

Well, in the worst case we can just "lie" and copy these methods into the class body, as if they were declared there.

And instead of extends BaseGeneratedMatcher, we could say implements IncQueryMatcher, to suggest the generic interface.

OK, I have now addressed this (sort of) - please check whether it is OK.

 

We could do the same for the Match class.

In the end I couldn't find anything important to include from base classes, so I left it as it was.

 

6. the generic API is demonstrated with the pattern FQN, which is only useful if the corresponding matcher factory has been registered, which typically happen with generated matcher factories only. In case of Patterns cobbled together at runtime, parameterize the matcher factory with the Pattern - especially that the comments explicitly say this.

very good point. the question is

- is this a supported/endorsed use case now?

- is there any working example on how to do this?

 Isn't this how the Query Explorer displays matches for patterns loaded from .eiq? 

OK, but the Query Explorer's internals are not part of the public API.

The question is:

- is "putting together" pattern definitions (as an EMF model) an "endorsed" usecase? Aren't there things to take special note of?

- is there a convenience API to do this starting from a "string" query (just like in the case of parser tests)? 

- is the programmatic loading and using of EMF Patterns from EIQ files straightforward?

Side note: I have noticed that interpreted Xbase can bring a significant/noticeable slowdown compared to the compiled variant. Shouldn't we add some option to the dynamic API of IncQuery to somehow "force" Java code generation and load the generated classes dynamically?

 

Anyway, does 

  IMatcherFactory<? extends IncQueryMatcher<? extends IPatternMatch>> factory

help maybe?

Let's discuss this on the API review meeting tomorrow.

cheers

Istvan

--

Istvan RATH, PhD

Research fellow
Budapest University of Technology and Economics

Fault Tolerant Systems Research Group