Possibly add an explicit exclusion pattern parameter
Closed this issue · 2 comments
Wildcard Match currently has a feature that enables exclusion patterns when the appropriate flag is enabled and the pattern starts with !. This was a requirement for Rummage and the entire reason we added the functionality. With that said, some people may want to use exclusion patterns without using !. The way to do this would be to have an explicit parameter that accepts exclusion patterns.
I haven't looked into how complicated this may or may not be, but it may be nice to consider an exclude parameter that can take a list of patterns. All patterns in exclude would be considered exclusion patterns and the NEGATE flag would not apply to them at all. As a matter of fact, users should use either NEGATE or exclude not both, but we would not restrict it, we would just ensure the NEGATE flag did not apply to the exclude patterns.
We may need to actually limit things to NEGATE or exclude. It'll make it easier to track limits and such. If we didn't want to fail things, we could simply just ignore NEGATE if exclude patterns were provided.
The problem is not actually with tracking limits as this can actually be handled fine, but the problem is actually ensuring unique patterns. If we are ensuring only unique patterns, we keep a set of "seen" patterns. This becomes more troublesome if NEGATE is enabled as inline exclusion !test != test for an exclusion list.
These two different approaches to negation fundamentally work differently. To combine these, we'd have to normalize exclude lists to match our ! format. This adds more unnecessary overhead.
Instead, I think that we should ignore NEGATE and NEGATEALL if exclude is provided. A user should decide whether they are supporting inline exclusion patterns or external exclusion lists. If they use both, we'll decide for them, and it will be to ignore the NEGATE and NEGATEALL flags. If documented, I think this will be fine. Then we can track exclusion list pattern duplication and general pattern duplication in separate calls without having to share their knowledge and normalize exclusion patterns.
The WcMatch class has always been designed with inline exclusion baked in. There is no need for us to add an explicit, external exclusion list. As a matter of fact, WcMatch doesn't let you turn off inline exclusions. If there was a demand to change this, we may consider it, but currently, the main customer of the WcMatch class is our own Rummage app, and it will always be using inline exclusion.