You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The method TermMatcher::constant offers implementers a way to optimize their processing of TermMatchers: instead of naively generating all triples and filtering them using TermMatcher::matches, they can use the constant term to only generate the necessary triples.
This is very well for some implementations, but it makes it impossible to optimize on more complex matchers, which some implementations could do. It might be interesting to extend TermMatcher::constant into a more complex method(call it optimizationHint for example), which would return an enum as suggested below. Different implementations would be able to take advantage of different kinds of hints...
Proposal:
enumTermMatcherHint{NoHint,// you need to call the match method...Constant(Term),// matches a unique termList(Vec[Term]),// matches a pre-determined list of termsRange(Term,Term)// matches any term in the given range (given some total order on terms)// ... anything else?}
NB: Any would still return NoHint, and that's OK, because calling Any::match, which is implemented as { return true }, will be optimized away anyway.
The text was updated successfully, but these errors were encountered:
NB: Any would still return NoHint, and that's OK, because calling Any::match, which is implemented as { return true }, will be optimized away anyway.
Rectification: Graph::triples_matching implementations will generally not need a specific hint for Anybut implementations of MutableGraph::remove_matching and MutableGraph::retain_matching could benefit from such a hint.
This issue emerged from #153 .
The method
TermMatcher::constant
offers implementers a way to optimize their processing ofTermMatcher
s: instead of naively generating all triples and filtering them usingTermMatcher::matches
, they can use the constant term to only generate the necessary triples.This is very well for some implementations, but it makes it impossible to optimize on more complex matchers, which some implementations could do. It might be interesting to extend
TermMatcher::constant
into a more complex method(call itoptimizationHint
for example), which would return an enum as suggested below. Different implementations would be able to take advantage of different kinds of hints...Proposal:
NB:
Any
would still returnNoHint
, and that's OK, because callingAny::match
, which is implemented as{ return true }
, will be optimized away anyway.The text was updated successfully, but these errors were encountered: