Small remarks and questions

[ExpHP]

Hi, I think this package is a really cool concept! I was working through this code and adapting it to Rust (code not yet published), and a number of questions and comments arose.

These ones are pretty small so I've collected them into one issue. Here's a checklist, which I think(?) you will have the power to edit:

• matchInput inconsistency with epsilon
• REST_MISMATCH is dead code(?)
• confusing initialization of cache in toGlobHelper

---

matchInput inconsistency with epsilon

Currently, matchInput('**/*', '') = '', because this line does not check the length of b. Since all other matches involving epsilon fail (presumably because epsilon edges were already treated earlier in the code), I assume this is an oversight?

REST_MISMATCH is dead code(?)

Is REST_MISMATCH a leftover from some debugging work? It appears that toGlobHelper is unnecessary and match_brackets is always true.

confusing initialization of cache in toGlobHelper

cache is initialized with some empty strings, but later is seen to contain arrays. Eliminating the initialization lines don't break any test cases, so it seems okay to remove?

[guncha]

Hi @ExpHP,

Glad you found it useful! I just looked at the code and I have no idea how it works (even though I wrote it), but I'll try to answer your questions.

1. Is matchInput('**/*', '') = '' correct? I can't tell either way. That function is trying to find the most specific pattern between the two. Think about specificity here in terms of all the possible strings that the patterns match. Since **/* matches everything, the code just assumes that the other pattern must be more specific (matches less strings). I think you're right, it should skip that case if one of the patterns is ''.
2. Yes, it's dead code, as it's currently written. It was introduced in 40b2292#diff-66d14bf3d12add1ab55262539d9889e0R326. The idea was to try to find the simplest representation of the glob when converting it back to a string, but I think some improvements in culling the states might have made that obsolete.
3. I think you're right again. I might have been doing some benchmarking and noticed that prefilling the cache with empty values would speed it up since the JS engine can see it's used as a simple hash map and not try to find a hidden class for it. If anything, I should have used undefined instead of an empty string.