-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nom matching #26
Nom matching #26
Conversation
Just a quick life sign, I will try to review the implementation somewhen next week. I am already pretty happy to see nom matching getting implemented since this should resolve #23 . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's my first take on the implementation. Looks promising but we may need to optimize some parts.
Co-authored-by: Andreas Linz <klingt.net@gmail.com>
Co-authored-by: Andreas Linz <klingt.net@gmail.com>
As far as I'm concerned this can be merged (once the remaining conversations are resolved). Some (potential) follow-up TODOs:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, good work and sorry for the delay 🙈
From my side as well, only thing, the range flip, should be removed in my opinion.
All the potential follow-ups are reasonable and should be defined in GitHub issues. |
I haven't noticed that you now fail on reversed character ranges otherwise I would have merged this already. Anyhow, I created three follow-up issue based on the optimizations of #26 (comment). Thanks again for the contribution! |
Thank you for the great review! |
This is my attempt at implementing a nom-based matcher to get rid of regex dependency as explained in #23.
It works by parsing the address pattern and separating it into
AddressPatternComponent
s. When matching, the matching method iterates over the components and applies the correct nom parser for each component, consuming the address to be matched part by part. If everything is consumed and every component parser was run, the match is successful, otherwise it's a failure.The one tricky thing to implement were wildcards in combination with other elements (e.g.
/foo/*{bar,baz}andsometext
). The wildcard parser was implemented to be greedy, so it tries to consume as many characters as possible.This is still early WIP. The matcher is fully implemented, but everything around it needs work (documentation, removing unused functions, etc.), but I'd be happy about comments.