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

[Istvan Rath <rath@xxxxxxxxxx>]

Hi,

I think this is better discussed in public.

1. since the source code of the Match and Matcher classes are already mangled, couldn't we just add the most important inherited methods, such as getAllMatches() ?

getAllMatches is actually included there. What else would you like to see that is not there at the moment?

Btw. I'm still looking for a _good_ suggestion on how to "include" inherited methods (other than pointing to the Javadoc, which is what we have now).

 

2. from the generated MatchProcessor code, I think the abstract method is what we want to emphasize, not the other one

agreed, done

 

3. under "Matching with partially bound input parameters and using result set projections", we have this line:

  matcher2.forEachMatch( matcher2.newMatch(null, "A") , new EClassNamesProcessor() {

how about:

  matcher2.forEachMatch( null, "A" , new EClassNamesProcessor() {

instead?

Or getAllmatches(), so that the processor distract us. 

Of course, we should also show the newMatch() syntax as an alternative, but it is not necessary to always wrap parameter tuples into matches, when we have all those nice pattern-specific generated methods. 

agreed, done

 

4. in the next code block, 

  ...matcher2.newMatch("null",...

should be 

  ...matcher2.newMatch(null,...

done

 

5. on the advanced page, executeDemo_GenericAPI uses an unmanaged engine, wipes, etc., even though these concepts will only be introduced later

true, the advanced page is more of an outline at the moment, I'm in need of ideas/suggestions what to do there and how.

 

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?

 

7. in the same code block, the null check should rather be done on the matcherfactory, right?

right, I adjusted the code and while doing so, I discovered some additional generics issues (note included in https://trac.inf.mit.bme.hu/VIATRA/wiki/IncQuery2/Meetings/20130416)

 

cheers,

Istvan

--

Istvan RATH, PhD

Research fellow
Budapest University of Technology and Economics

Fault Tolerant Systems Research Group