Use as text matcher against search text?

[bradparks]

I'd like to use this to match text, like someone would with a search engine, e.g.

e.g If I had the text

this is a test of the system
brad and his dog

this search would match
test or you and (brad and dog)

but this one wouldnt
test and rabbit

I could use a custom function, but for this use case, the variable names are actually the variable values.

Is there an easy way to do this? I'd prefer not to use a custom function, as I want it to be natural for my end users.

[m93a]

Here test, you, brag and dog would be interpreted as variable names – this behavior is baked into Filtrex and there's really no way around. If you're not happy with something like contains("test") or contains("you") and contains("brad") and contains("dog"), you could add special string operators to the language, but this would probably be as difficult as writing a new filter engine from scratch.

Edit: When I think about it more, maybe overloading the logical operators could add some ergonomics. I mean, boolean values would behave the same as they did, but for the rest, instead of coercing to boolean, the compiler would construct an expression tree and then, when you apply a function on it, it would distribute the function to the inside. Let me demonstrate this on an example:

This thing:
contains( "test" or "you" and "brad" and "dog" )

Compile-time translates into this:
contains("test") or contains("you") and contains("brad") and contains("dog")

The problem with this behavior, however, is the dichotomy between booleans and other types, as it would have to be decided on runtime, depending on the type information only available on runtime. And adding different operators like & takes away the readability and similarity to human language, so does wrapping the "distributed" sections into eg. braces.

So while the idea sounds good, I haven't yet come to an solution.

[bradparks]

How about this idea?

#28

I know it mostly makes sense only for booleans, and other operators don't quite make sense, but it works for those cases, which is mostly what i want... I actually coded that up, then popped in here to comment and saw your comments ;-)

[m93a]

I love your idea, it provides extensibility that fits the library very nicely! However, it seems that @joewalnes lost his interest in this repository a while ago. I'm strongly considering making my fork the default and hijacking the NPM module (see issue #22)… 🤔

[m93a]

I was just randomly browsing the issues and felt a sudden urge to point out this was implemented in the end. Tutorial for a text matcher in filtrex can be found here.