Package jetbrains.mps.generator.impl.template

Interface QueryExecutor

  • All Known Subinterfaces:
    QueryExecutionContext
    All Known Implementing Classes:
    DefaultQueryExecutionContext, QueryExecutionContextWithTracing
    public interface QueryExecutor
    This is not an attempt to make new and nice replacement for QueryExecutionContext, rather an attempt to fix shortcomings arising when using it. Hence it's very similar to the QEC. This is an indirection mechanism to invoke queries, suitable if there's need to perform extra activities (like tracing/model access recording) in addition to query execution. Note, this might change once we encapsulate all queries into objects. Then, factory for these query object may augment them with proper extra tasks as needed, without need to have this indirection mediator. Meanwhile, however, we keep this and slowly migrate methods of QEC here, with proper/better API. IMPORTANT: One real benefit of using indirection mechanism of this class is handling of user-code exceptions. While for reflective calls we can do that in query implementations from ReflectiveQueryProvider, we can't expect generated non-reflective queries to execute without a RuntimeException always. This indirection allows us to keep this handling in a single place (and report e.g. with dedicated GFE subclass). Besides, we can provide 'straightforward' QE implementation that doesn't do additional try/catch for templates from deployed generators to speed-up things a bit (if/when we are pretty confident our generators work good) Note, with extra layer of RT objects as Rules, for a query that is associated with a Rule, it's not always straightforward whether generator implementation shall run it directly through QueryExecutor or shall delegate to Rule implementation instead (which, in turn, would either use QueryExecutor (for interpreted), or invoke code directly (for generated templates)). Consider TemplateWeavingRule and its contextNode and anchorNode queries. Generator implementation may invoke these directly with QueryExecutor or delegate to rule. In former case, the role of TWR itself becomes uncertain, in latter, the question "why don't we do the same for other queries" is raised, and there's yet no good answer to this one.