Parse search strings as byteseek regexes, or just convert to byte arrays?

[nishihatapalmer]

Parse search strings as byteseek regexes, or just convert to byte arrays?

[nishihatapalmer]

I guess those constructors just throw CompileExceptions. It only affects you if you use those constructors - as it should.

[nishihatapalmer]

This is essentially a convenience constructor. Either a string is a byte array, or it's a regex. In either case we already have constructors for the outputs (SequenceMatcher or byte array). And the byte array can also be modelled by e a SequenceMatcher.

What gives the best convenience?

[nishihatapalmer]

So - SequenceMatcher constructor is the only general constructor for SequenceSearch algorithms.

[nishihatapalmer]

Downside of making String constructors for search algorithms process regexes, is it creates a hard dependency on all search algorithms to the byteseek sequence matcher compiler and regex parser.

[nishihatapalmer]

Currently, matchers and searchers don't depend on the parser and compiler in any way.

[nishihatapalmer]

The only excuse for such a higher level dependency is convenience - which is what this is.

Is the convenience of instantiating hex string (or more complex syntax) searchers directly worth the dependency it creates?

[nishihatapalmer]

I don't think a hard dependency between the Searcher and Compiler package will really hurt anything.

It's a general design principle to try to keep them as cleanly separated as possible, but this is a case where we already had a support question raised by a user. They expected (or wanted) to be able to do this.

[nishihatapalmer]

I'm going to explore using SequenceMatcher compilers directly in the SequeneSearcher String constructors.