-
Notifications
You must be signed in to change notification settings - Fork 231
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
Add EntityResolver and DocType event #583
Conversation
6367dcc
to
236086f
Compare
Please add an entry to the changelog and fix the typo in the message of the last commit |
236086f
to
060b565
Compare
@dralley Done |
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.
Thanks for your work! I think PR will benefit if you make such changes: split it into three commits (rebase your branch and force push it):
- the first one that synchronizes documentation between variants of
Event
andPayloadEvent
- the second one which relaxes requirements to
resolve_entity
parameters fromFn
toFnMut
. That commit should relax requirements in all places and note this in the changelog - the third one which adds an
EntityResolver
trait etc. I was too quick in my comment regarding theresolve
method. Becauseresolve_entity
are now would beFnMut
, the trait could be defined asAdd tests for the new feature in this commitpub trait EntityResolver { fn capture(&mut self, doctype: BytesText); fn resolve(&mut self, entity: &str) -> Option<&str>; }
) -> Result<Cow<'input, str>, EscapeError> | ||
where | ||
// the lifetime of the output comes from a capture or is `'static` | ||
F: Fn(&str) -> Option<&'entity str>, | ||
F: FnMut(&str) -> Option<&'entity str>, |
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.
After consulting with the standard library I think, it's a good idea, but that change should be done in it's own commit and have it's own changelog entry.
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.
It's not immediately clear why it's necessary, as the docs say:
Use FnMut as a bound when you want to accept a parameter of function-like type and need to call it repeatedly, while allowing it to mutate state. If you don’t want the parameter to mutate state, use Fn as a bound; if you don’t need to call it repeatedly, use FnOnce.
What state do you expect the entity resolution process to mutate? I would think it would be read-only... Or is it more a matter of just providing the flexibility anyway if there are no downsides to using FnMut
in our context?
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.
Yes, it is just to provide flexibility and be consistent with similar std API, such as Iterator::map
.
adaedb0
to
cd42ced
Compare
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.
This is almost good, just need to polish some things.
Actually, the first commit did not what I want. I meant that you to change the doc strings of all matching Event
and PayloadEvent
variants to be the same by keeping the best description. And then in the third commit add a new variant to PayloadEvent
(so it would be just a copy of the corresponding variant from Event
)
d9f2446
to
d99f613
Compare
I'm not sure what you mean by this. Should all the enum variants be the same between |
Just the docs, because |
d99f613
to
9b5e0e9
Compare
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.
I've updated the PR, with the following changes:
- Allow
EntityResolver::capture
method to fail - Change the example on
EntityResolver
more close to possible real world implementation - Make
resolver
module private and instead re-export trait and type inde
module
Unfortunately, making EntityResolver::resolve
taking &mut self
leads to strange error, that the returned reference could not outlive the captured object in the closure. This is strange, because returning the same reference while resolver is read-only is fine. So if you wish to make lazy parsing in resolve
, you should use Cell
or similar.
@dralley, could you look at this once again? It seems good for me now and I plan to make another patch release after merging that.
Codecov Report
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more @@ Coverage Diff @@
## master #583 +/- ##
==========================================
+ Coverage 64.19% 64.36% +0.17%
==========================================
Files 34 35 +1
Lines 16631 16676 +45
==========================================
+ Hits 10676 10734 +58
+ Misses 5955 5942 -13
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 3 files with indirect coverage changes Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
fixes #581
PayloadEvent::DocType
EntityResolver
so that unknown entities can be resolved.unsescape_
functions to useFnMut
instead ofFn
forresolve_entity
parameters.