The Context implementation orchestrating most of the matching process.
The parsing process works as following: After the rule tree (which is in fact a directed and potentially even cyclic graph of {@link Matcher} instances)has been created a root MatcherContext is instantiated for the root rule (Matcher). A subsequent call to {@link #runMatcher()} starts the parsing process.
The MatcherContext delegates to a given {@link MatchHandler} to call {@link Matcher#match(MatcherContext)}, passing itself to the Matcher which executes its logic, potentially calling sub matchers. For each sub matcher the matcher creates/initializes a subcontext with {@link Matcher#getSubContext(MatcherContext)}and then calls {@link #runMatcher()} on it.
This basically creates a stack of MatcherContexts, each corresponding to their rule matchers. The MatcherContext instances serve as companion objects to the matchers, providing them with support for building the parse tree nodes, keeping track of input locations and error recovery.
At each point during the parsing process the matchers and action expressions have access to the current MatcherContext and all "open" parent MatcherContexts through the {@link #getParent()} chain.
For performance reasons subcontext instances are reused instead of being recreated. If a MatcherContext instance returns null on a {@link #getMatcher()} call it has been retired (is invalid) and is waiting to be reinitializedwith a new Matcher by its parent
|
|
|
|
|
|
|
|
|
|